This message was deleted.

code spaces is amazing when it’s up. it’s pricey as well tagging @Lou Bichard who can probably can give thoughts

👋 Thanks Andrew. Disclaimer, I work for Gitpod (as a PM). But I’m a former platform engineer, so I know the pains 😄 I’ll talk mostly about Gitpod here, as that’s obviously my stronger area of specialism. Some of what I say will apply to Codespaces, but some will not. A point I’d like to mention is that GitHub Codespaces is a multi-tenant solution. Many of our customers find that is insufficient, so Gitpod has an offering called Dedicated which runs in our customer(s) cloud account to solve that. Alas, anyway, let’s move on… In short, we see a lot of usage and interest from platform teams in our customers. If your take on Platform Engineering is that you want your developers to move faster, CDEs can be a very powerful capability to have in your toolbox. Some example use cases: 1. Onboarding - By automating the steps to get started on a repo or project, such as baking platform tools into a default image, developers always have the latest tools, new repos have an out-of-the-box experience [1]. 2. Secrets - A commonly overlooked aspect is secrets [1]. Gitpod connects to vault, AWS, other major clouds secret stores to pull secrets. That solves the issue of secrets sprawl on your developer machines. If you need to rotate a secret, you don’t have to ask, you just update it in your store and it federates to all your users. 3. Portal integration - Many of our customers integrate Gitpod into their internal developer portal(s) so that developers can jump into a workspace at any time with a single click (integration is as simple as having a URL to your gitpod instance with the repo URL). Many customers asked for a CLI also [1] so they can deliver CDEs -as-a-service to their developers through their own CLI 🙂 I could go on here. There really are a lot of use cases, it depends on what’s important for your organisation. I recently updated our use cases page, that talks about just some of the ways you can impact your developer velocity with a CDE. If you (or anyone else here) wants to talk about CDEs and platform, I’m more than happy to hop on a call (calendly link) 🙂

@Lou Bichard thanks a lot for the valuable answers. Actually in our oganization, we have lots of diversity in terms of tech stack. Our company developing, SDKs, mobile application with iOS and Android, and also web services with Java, Node.js and etc

I used to need to handle 35+ OSes for dev and CI for a product with 1B+ installs and 1k engineers . We didn’t try and fit the mobile and desktop stack into the CDE. Practically what had more value was the CI stack bc the number of developers on desktop and mobile was a fraction of the number on backend. Platform spent more time on things like ensuring the middle ware libraries, mobile CI/desktop CI, desktop deployment, vs fixing the development environment.

> The main thing that I d like to learn and understand, how can CDE will be generic? As a platform team, should we create some templates for each programming language or what will be the best way of doing take a benefit of CDE? Lots of CDEs are based on Docker images. Depends on how your teams are setup. You might want to create images that are default for everyone, then create more specific ones. For example, we have some prebuilt images, but likely you want to build some yourself for your use cases with different packages, libraries, etc. > Getting XCode, Android Studio, Android build tools I’m not aware that Android Studio directly supports remote development. The rest of JetBrains does, if you can install plugins into IntelliJ that create the experience you want, that could work. https://www.jetbrains.com/remote-development/gateway/. > Having a live simulator in the browser like expo Snack would make it simple to get people (temporary) up and running, even if they don’t have a powerful machine. Snack looks like web technology. Running that in a CDE would be trivial. I tried setting it up just now, but it’s bombing lots of errors. I think the maintainers haven’t done a great job with the docs up to date. But if you work through that, just a basic configuration in your repo, and opening a Gitpod workspace would work with Snack.