I am the project lead creating a brand new inventory system for a warehousing service. This is probably the biggest project that I have been in terms of number of people working on it and the sheer number of lines of code that we had to write. Everyone in the team was agile and mature and I knew that software development is going to be smooth in that area. What bothered me though, was everything else, mainly how to tie them all together. In my years of experience leading teams, I recognized that they develop silos where they ensure that they do their job but do little of anything else. This led to the testing team blaming the deployment team, the development team, blaming the testing team and so on. So, I cried for help and the corridors of the interwebs responded with a catchy word – DevOps.
What is DevOps and How It Will Help My Inventory System Development
DevOps has been coined to describe a new philosophy in software development. While there are a lot of definitions of DevOps out there I prefer this one. DevOps is a mindset where all aspects of software development, testing and deployment is a shared responsibility of the entire team. While this is simplistic, I believe that this definition captures the exact essence of DevOps and most importantly describes its main purpose. I do not disregard the importance of the tools and practices that are commonly associated with DevOps but without understanding first what you are trying to solve, the solution may not be as useful.
Silos exist in any engineering team which is the reason why leads are assigned to fill those gaps. But in the fast paced world of software development, sometimes it is just too much for a person, or even a group of persons to stay on top on. Even with our advances in technology, there is just no way of making sure that crucial changes in one silo is effectively communicated to other affected silos. Teams that rely on tools like Slack and Teams cannot easily keep up with the flow of information especially if all information is broadcasted to the entire team.
When I first introduced DevOps to the team, the collective response was largely apathetic. Most of them believe that we are already doing some iteration of the concept and we do not need to add another layer to it. After all, we are already familiar with the majority of tools and practices that are used in DevOps. Then I started pointing out some key flaws in our previous development cycles.
The first flaw was the most obvious one and that was the lack of a development pipeline. Pipelines in software development represent the steps that are taken to get a feature from requirements into release. Like an actual pipeline, this should be sturdy, with replaceable parts and the whole process is repeatable. I started off by presenting my initial CI/CD pipeline design. It showed how features are chunked into tickets, developed by individual teams, tested in integration and released in versioning. Then someone asked the crucial question. Who would be the one to manage the pipeline and make sure that everyone was following it? That is when I introduced the DevOps team.
Choosing a DevOps Team for an Inventory System
The most difficult task in establishing DevOps within the team was choosing the DevOps team to oversee it. Since DevOps is a fairly new concept, I knew I was not going to be able to find formulate my job requirements by basing it on other team’s experiences so I had a very simple method in picking them. First, I chose which of the team had the drive to learn and try out new things. Second, they had to be mature enough to deal with talking with multiple stakeholders including point persons in each silo. And finally, the entire should be multi-faceted. The first one, I designated as lead was the automation lead. And assisting him was a tester turned developer who has extensive knowledge on the platform we are developing on. And the two newbies who are well versed in infrastructure. They were my dream team and I knew I could count on them.
Development Automation of An Inventory System
The tooling aspect of DevOps is perhaps the most crucial part of DevOps integration. Choosing the right tools could spell success or doom of the project considering the amount of extra work necessary to get acquainted with the tools, the prices that they normally go for, and the apparent need for everything to just work together.
The first decision that I made was to consider containerizing the entire inventory system. We already had a mature design architecture following the microservice software pattern. Moving to containerization was simply the intuitive choice. There was one major player in that technology and since it is open source and had a strong community base, we opted to use Docker.
Containers presents a lot of advantages both in deploying the inventory system but in the DevOps side of things as well. For instance, the development environment can be sprung from containers to enable developers to have a feel of what the actual production environment is like. This idea of sharing the same environment for development, production, and as well as testing is paramount in establishing proper DevOps culture.
Finally, at the heart of DevOps is automation and here is where there is a lot of flexibility in tooling. For instance, our inventory system uses a combination of microservices and enterprise databases in the backend while also using both browser based and desktop based frontends. Because of the setup, integration tests built from scratch can be quite a hassle. However, a way to circumvent this problem is simply by using automated configuration management. By writing the configuration in files, recreating environments is as simple as running the configuration. Automation plays a key role in DevOps.
Laila Azzahra is a professional writer and blogger that loves to write about technology, business, entertainment, science, and health.