First we build everything in containers to ensure all devs use the same versions of build dependencies for all projects, be it node, go, java or python. The Dockerfile for the build environment is checked in with the code, and also used in our build servers.
Secondly we package our tools in docker containers to get them available in lots of different teams, no matter what base technology they are using, and also no matter what os they are using.
For example tools for working with our secrets manager or deployment tools which has prepackaged kubectl and helm and gets configs injected either from host on devs computers or as env on build servers.
We also like to develop selenium e2e tests towards browsers running in containers, before expanding to run on our device farm.
And lastly we host quite a few kubernetes clusters onprem that are being used both for dev, test, stage, and prod for applications from different teams.
We are still not full-fledged devops yet, but working our way there. Our current setup help alot in the journey as ops help during development and dev starts to worry about how things are hosted and monitored with help of ops. The deployment tool, which is build on helm with some extra metadata and custom extentions, is used to deploy everywhere. So the devs gets freedom of using what ever tech they want on their side as long as its packaged in docker containers and can be deployed with the ”extended” helm chart using our deploy tool. Then our ops just need to handle everything in the same way once its running in our clusters.
…oh yeah… almost forgot! We also have migrated all our custom tool servers to docker and deployed in our dev-kubernetes clusters. Lots of different stuff, from onboarding tools to deamonsets helping to keep logs to max 29days.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We have a couple of use cases.
First we build everything in containers to ensure all devs use the same versions of build dependencies for all projects, be it node, go, java or python. The Dockerfile for the build environment is checked in with the code, and also used in our build servers.
Secondly we package our tools in docker containers to get them available in lots of different teams, no matter what base technology they are using, and also no matter what os they are using.
For example tools for working with our secrets manager or deployment tools which has prepackaged kubectl and helm and gets configs injected either from host on devs computers or as env on build servers.
We also like to develop selenium e2e tests towards browsers running in containers, before expanding to run on our device farm.
And lastly we host quite a few kubernetes clusters onprem that are being used both for dev, test, stage, and prod for applications from different teams.
We are still not full-fledged devops yet, but working our way there. Our current setup help alot in the journey as ops help during development and dev starts to worry about how things are hosted and monitored with help of ops. The deployment tool, which is build on helm with some extra metadata and custom extentions, is used to deploy everywhere. So the devs gets freedom of using what ever tech they want on their side as long as its packaged in docker containers and can be deployed with the ”extended” helm chart using our deploy tool. Then our ops just need to handle everything in the same way once its running in our clusters.
…oh yeah… almost forgot! We also have migrated all our custom tool servers to docker and deployed in our dev-kubernetes clusters. Lots of different stuff, from onboarding tools to deamonsets helping to keep logs to max 29days.