🎯Aim
When spinning up a new project or on-boarding a new developer, I want to process to be as smooth and easy as possible, so I can get people doing the right thing with the right environment as quickly as possible
📕Context
We work on lots of different projects and code bases. Making sure that you have the right development tooling and the right version for all of them at the same time can be time consuming. Especially for new starters.
Traditionally for backing services (Postgres, Redis etc.) we have used Docker containers, and Docker compose. Some have extended this to the development of the app itself. This works but impacts the ergonomics of development with actions such as installed dependencies needing more complex command lines. For example
poetry add thing vs docker compose run app poetry add thing
Dev containers take this concept, and improve the ergonomics. They allow your IDE/development environment to feel like you are working locally, but the application is actually inside a docker container.
So if you open a terminal - it is inside the running container. Or if you use your IDE to run tests, or the application itself - it is inside the container. All whilst appearing exactly as it would if you were doing it locally.
The dev container can also be part of a compose set so you get all your backing services too.
Dev containers is a general (emerging) standard as is not tied to any specific IDE, or even an IDE at all. Both VSCode and the Jetbrains range of IDEs have good support already. They are also optional - you can use them if you want to, but are under no obligation to do so if you would rather not.
📝Relevant resources/doc's/people
✅Acceptance Criteria
- Projects created from this template provide a functional devcontainer in which to develop the project
- The dev container should provide a standard set of tooling (poetry (or UV going forward, invoke, git)
- The dev container should allow the user to interact with git as if they were in the local machine (i.e. their git credentials and config should be available)
- the dev container configuration must rely on features only supported by a single IDE.
- Although it can provide configuration that makes life in those IDEs easier (e.g. vscode plugin config)
🎯Aim
When spinning up a new project or on-boarding a new developer, I want to process to be as smooth and easy as possible, so I can get people doing the right thing with the right environment as quickly as possible
📕Context
We work on lots of different projects and code bases. Making sure that you have the right development tooling and the right version for all of them at the same time can be time consuming. Especially for new starters.
Traditionally for backing services (Postgres, Redis etc.) we have used Docker containers, and Docker compose. Some have extended this to the development of the app itself. This works but impacts the ergonomics of development with actions such as installed dependencies needing more complex command lines. For example
poetry add thingvsdocker compose run app poetry add thingDev containers take this concept, and improve the ergonomics. They allow your IDE/development environment to feel like you are working locally, but the application is actually inside a docker container.
So if you open a terminal - it is inside the running container. Or if you use your IDE to run tests, or the application itself - it is inside the container. All whilst appearing exactly as it would if you were doing it locally.
The dev container can also be part of a compose set so you get all your backing services too.
Dev containers is a general (emerging) standard as is not tied to any specific IDE, or even an IDE at all. Both VSCode and the Jetbrains range of IDEs have good support already. They are also optional - you can use them if you want to, but are under no obligation to do so if you would rather not.
📝Relevant resources/doc's/people
✅Acceptance Criteria