At Fearless, we support many clients on site. This post documents the learning process we went through with one team of developers to enter the world of DevOps.
As with many teams discovering the world of DevOps, we quickly realized that many of the practices we followed were heading in the right direction. As we started researching, we were amazed to find out that the things we found frustrating had already been solved by the DevOps community. It was a great awakening that led to our team becoming automated, available, and manageable. We still have a long way to go and we certainly made some mistakes along the way, but our process is much more refined now than it was two years ago.
For some context, our team has been running a suite of tools for developers on an intranet. We have focused on using open source tools, such as Gitlab, Jenkins, and Redmine, to ensure we support the open source community with bug reports and occasional fixes. After accepting requests for new tools from devs in our community, we quickly found ourselves supporting around a dozen different applications, each using its own its own language (Ruby, Node.js, Java, Python, etc) and running its own software/library/tool stack (Rails, Express, Spring, MySQL, PostgreSQL, MongoDB, ElasticSearch, Solr, etc, etc, etc).
Before we knew it, we were in way over our heads. It’s next to impossible to remember the deployment and update process for such a wide variety of systems, each of which was configured on-the-fly and directly into production. When a system needed support or updating, even finding the directory where we installed the application was a chore.
This led to one of our first unintentional shifts into DevOps: Consistency. Without having the luxury of using a consistent software stack, the least we could do is ensure all our applications are installed in the same place. We made this change with a relatively small time investment, and our applications suddenly became much easier to support.
To an outside observer, this may not seem like a revelation of any large magnitude, but internally it was a huge mental shift. The realization that we are in control of our environment, systems and applications was an awakening. We understood that when we were frustrated by a process, we had the power to change it. This is the power that DevOps teams must wield to mold their development environment into something manageable.
In the next post, I will discuss how we created a consistent application configuration process, and what we could have done better.