Inthi article I want to shed light on the often unnoted role of Docker as a build environment in larger and legacy applications that regularly must be maintained and extended.
This is precisely why we use an in-house Drone deployment for our CI purposes.
I also run a Drone environment and with GitHub Enterprise, it works really well. Other names in that Docker + GitHub space are Travis CI and Circle CI.
Putting on the build and release engineer hat, using Docker for builds is great if only for just being able to track the changes to the build environment. Other “configuration as code” options exist but Docker puts the focus on the development process instead of just the sys admin process. A developer can’t install a new dependency locally and forget about it. If they use the exact same Docker image as the central build to do their development, then they have to add that dependency via the Dockerfile. Keeps it documented and keeps it managed.
I started out by using Docker for building the software we’re developing, but found that it can easily be optimized by switching to Mock. As we deploy, primarily, on CentOS/RHEL using Mock makes perfect sense. By running the unit tests at build time, in the %check section of the RPM spec file, I also no longer depend on Travis CI and have the additional benefit that the tests run on exactly the platform they will be deployed on.