> people are using them for their dev environments [?]
Yes, we use a container for dev environment so that we can share the same env across all the team. If it's decided that we need 1 more tool in our toolbox, the script that generates the container is updated (the script is version controlled in the repo too), the CI/CD generates a new container version, all the devs can now use the same NEW environment.
We actually use the container as image for (remote) virtual machines, so we don't really compose multiple containers.
The container has all the tools (for several languages) that we use as a team.
IDEs and debuggers can connect through ssh.
> post-development workflow do you ever use separate containers for build and test?
We build different flavors of the final packaged application, for example:
- production flavor: uses a minimal, nonroot container base image (see: https://github.com/GoogleContainerTools/distroless)
- debug flavor: includes few extra debug tools inside the container
Yes, we use a container for dev environment so that we can share the same env across all the team. If it's decided that we need 1 more tool in our toolbox, the script that generates the container is updated (the script is version controlled in the repo too), the CI/CD generates a new container version, all the devs can now use the same NEW environment.
We actually use the container as image for (remote) virtual machines, so we don't really compose multiple containers.
The container has all the tools (for several languages) that we use as a team.
IDEs and debuggers can connect through ssh.
> post-development workflow do you ever use separate containers for build and test?
We build different flavors of the final packaged application, for example:
- production flavor: uses a minimal, nonroot container base image (see: https://github.com/GoogleContainerTools/distroless)
- debug flavor: includes few extra debug tools inside the container