Streamlining Workflows With Docker
Every week, our team puts most of our hours towards helping our long term, stable client applications stay up to date. From dependency upgrades to changes in the code base, we make sure these older rails apps are kept secure and functioning. Some of our clients choose to hire us because the amount of time spent securely maintaining their app does not justify the cost of hiring a full-time developer, while others are looking for a trustworthy assistance after losing a key developer.
No matter the state of the application when we take over maintenance, it becomes our job to ensure functionality and security. Some applications reach us with code that is so old that “legacy” seems an understatement. Many of our developers have not been coding for 20+ years, and do not have cached copies of legacy code available. Their machines do not have versions of gems from 10 years ago that are no longer supported. Setup on these gems can be frustrating and time consuming. While onboarding 2 new developers in November, they clocked up over 10 hours each setting up a single project on their local machines.
This method is expensive and time-consuming. If every client required just 5 hours to set up, that’s an immediate cumulative team cost equal to the first month of maintenance, and we haven’t even touched the code yet! This is where Docker comes to the rescue.
Using Docker to grab images of gems and ruby versions, we are able to conduct a symphony of dependencies in a single command. The space needed for docker images can be higher than installing locally, but the pay off comes in the time saved. To see how we mitigated this, check out Jack Cullen’s article How to Set Up and Encrypt an External SSD and Run Docker Images Externally.
That same application that took 10 hours to set up in November? After switching the configuration to use Docker images, that setup went to 18 minutes the next time. That’s over 33 times faster, saving developer frustration and time.
Logistically, this allows all our developers to quickly pull down the code and run it locally for PR reviews, troubleshooting, pairing sessions, and group work. In addition to being able to efficiently consult with other developers on each client’s individual codebases, we also have the peace of mind of knowing that no client will be left unmaintained if the lead developer needs time off. After “Dockerizing” our applications, our back-up devs can simply pull down the repo and, with a couple of simple commands, be ready to work.
Now, when we take on a new client, their application is configured with Docker first. While this process can take time, we have found that this early investment at the beginning of a project more than pays for itself within the first few months.
Looking at the security aspect of our work, Docker gives us the ability to patch a vulnerability, test, and make a pull request quickly and seamlessly. Our vulnerability response is measured in minutes, not in weeks as some global companies do. Since the code is set to use Docker, any developer can hop in and help shore up client code without wasting precious time stumbling over the setup process.