Software engineering is an industry in which being somewhat lazy can be considered a good trait. It all comes down to how we approach menial, repetitive actions. We can do them manually over and over again and waste time. We can also automate these processes and focus on engineering the actual software.
Because we like creative work the most, we automate and these are our weapons of choice.
Software Development Life Cycle and Automation
Consider this rather generic example of a software development life cycle:
Of course, software development life cycle will differ depending mostly on the type of application, but also because of team preferences and company culture. It should be also accompanied by a good, coherent definition of done. Plus, it helps to maintain a good and clear relationship with a client.
It’s good to have a standard software development life cycle that’s company-wide because it ensures that the whole team “speaks the same language” - relates in the same way to the same point in development. It’s also very helpful in case of a new employee and junior developers that just graduated from their universities (where they learned only about the first part, coding).
Weapons of choice - tools for processes automation
When you think about it, many of the elements in the software development cycle can be automated. Of course, some elements still have to be done manually: code review, manual testing, and coding, at least for now. All the rest like building, automated testing, backups, deployment, and monitoring can be automated.
Here are the same elements of software development life cycle reshuffled with tools used for automation added.
One of our main tools is GitLab which we use to create pipelines which fuses some of the processes together. With the Docker’s help, GitLab automates several processes. It takes care of building, running automated tests and linters as well as pushing latest image version to the repository.
When it comes to deployment, we put our bets on Rancher - Docker orchestration platform. In short, it is an environment that helps us run Docker containers but also adds an abstract layer that manages hardware machines (f.e. servers). We can have multiple physical servers which through Rancher can be clustered into development, production and testing environment, and whatever you personally need. During a deployment of an service Rancher will decide on which machine it will be deployed. Usually, Rancher will pick a machine that has lower load. The takeaway is, as a developer I don’t really need to care on which particular machine the solution will be deployed. All I care is that it works flawlessly.
From automation to Continuous Integration and Continuous Delivery
Automation offers many pros. There’s no monkey business, or it’s reduced to bare minimum. You can focus all your brainpower and time on creative aspects of programming: finding solutions to problems and writing clean code that’s up to standards and requirements. Another positive trait of automation is, you can integrate freshly hired developers into your environment and processes practically on the spot.
A good processes automation enables the realization of Continuous Integration and Continuous Delivery approach to software development, which in turn can have a very positive impact for your company. First, high frequency of all subprocesses in the software development life cycle guarantees that code is always tested and clean. It can also lead to a mythical land of (almost) painless deployments. We all know that if something can go wrong during huge deployment it certainly will. By doing small deployments very often there are fewer things that can go wrong. Additionally, by each deployment, you and your team will get more and more experienced in deploying which is a very useful skill.
Moreover, features are delivered to a client considerably faster. This is especially important in case when our client’s systems require integrating with ours. Thanks to CI/CD a client is frequently updated on the progress. The moment we deploy a service is a moment in which client can integrate with it.
In general, without automating software development life cycle processes achieving the CI/CD approach would be very hard.
How to start automating
Like with many changes you need to start from yourself, for example, start from writing Makefiles to extract common tasks and have them easily accessible through abstract commands. Then scale the automation up, try to automate recurrent processes in your next project together with your team. If you're lucky, in time it may cause automation of company-wide processes. But beware, it is a slow and tedious process. You will probably also have to do it in your free hours and not during project’s budget hours. It may sound harsh, but think of it as an investment - you’ll have much less to do in the future projects.
However, it’s not as time-consuming as it may look. When you start your research, you’ll surely find a ton of tools (mostly open-source) that can do what you need with a simple setup. If your team prevents you from automating, change a team. If your company forbids it (without any real reason), change a company.
Finally, automation addicts. Once you start automating recurring actions, you’ll want to automate EVERYTHING, so watch out :)
*This article was created on the base of my talk at Szczecin’s Netcamp meetups for developers & IT industry. Full talk in polish with additional demo: