The term DevOps was originally coined during a 2008 Agile conference and was quickly picked up by the IT community. It has been defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality.” (Bass, Weber & Zhu, 2015, Chapter 1, p. 3). The success of implementing the Agile methodology in many companies led to the need for DevOps since they began to see the benefits of speeding up software releases and doing it more frequently.
While DevOps is often about software coders and infrastructure engineers, we often forget that it affects all the chains of software development lifecycle, such as quality assurance, application support, and management. This approach, therefore, cannot be implemented within one branch or one team and relies on united and non-isolated teams with shared responsibilities. For example, developers need to be more aware of the infrastructure and collaborate with the quality assurance team during the development stage and take part in unit testing. This collaboration also applies to system administrators, who may face changes with transitions to DevOps. They may confront technical changes, such as implementing design changes to the infrastructure architecture or non-technical ones, such as collaboration with a development team with a goal in mind to understand business requirements.
Within DevOps, automation is one of the approaches that can be taken to implement the methodology. Even though automation did not come from software development or even information technology, it has found a niche and has become a foundational approach to building new software. It helps save time and reduces cost by automating routine tasks and allowing more time to be spent on valued tasks. Another way of implementing DevOps is through infrastructure as a code. DevOps allows us to code the whole infrastructure, make changes and manage it. Most importantly, it allows the ability to have version changes that can be reviewed and accessed by the whole team. This approach appeared more recently with the rise of AWS and their infrastructure as a code platform. As of now, Amazon is not the only player in platforms, and other tools can be used as well.
We cannot really talk about DevOps without mentioning Continuous Integration and Continuous Deployment, also known as CI/CD. These terms appeared long before the term DevOps did but only became mainstream when Agile took over. Continuous Integration means integration of the code changes done to the central repository, which can be extended with additional build automation and automated unit testing, being run periodically or on commits. It gives DevOps its main advantage – speed. The secret here is collaboration and automation. It is unlike the old system where the developer usually commits changes once their task is completed, taking a week or two to finish. It makes merging the code changes time-consuming and difficult. This issue may be avoided with smaller tasks and regular and frequent commits, which would be automatically built and tested. We should not forget that even with all the benefits that automation testing gives us, a manual testing is still mandatory within a quality assurance workflow. This additional testing helps avoid major problems in the future.
Continuous Delivery extends Continuous Integration by making sure that all of the pieces can always be released to production. The goal here is to build your software and automate the deployment process. This way, any build can be released at any time and, of course, rolled back with the use of minimum resources. In the end, any commit that passes the automated test would be considered as release ready. This approach allows us to test new features and see them be released more quickly.
Another similar term that has a slightly different meaning is Continuous Deployment, which means that every change is automatically deployed to production; whereas, in Continuous Delivery the team ensures every change can be deployed to production but may choose not to do so.
Below is a list of the most common tools that are most commonly recognized within the IT community.
In the DevOps toolchain, we can differentiate a few categories with similar functionalities:
- Collaboration – any software to send/receive text messages, share comments with individuals and groups, and make calls—Jira, Slack, Skype, Outlook
- Planning – management tools to plan and keep track of the project or multiple projects—MS Project, Jira, Trello, Sticky notes
- Source Control Tools – SVN, Git, Team Foundation Server (TFS), Bitbucket
- Issue tracking – Jira, Zendesk, ServiceNow, Trello, Remedyforce
- Configuration Managements – Ansible, Puppet, Chef
- Continuous Integration – Jenkins, teamCity, CircleCi, GitLab
- Monitoring – Graphite, Logstash, Kibana, Splunk, Prometheus
- Deployment – Octopus, Packer, Ansible, Puppet, DockerDev Environments – Docker, AWS, Vagrant, Azure
In conclusion, DevOps is an approach and not a checklist or a set of tools. It consists not only of developers and administrators, but also of a collaboration between all the participants in the delivery of a software product. Consequently, there is the likelihood of looking for ways and processes to be automated and integrated into the development pipeline. Transition to DevOps will not happen quickly within an organization that chooses to adopt it, and results will not appear on day one. However, the benefits accumulate over time, and as they grow, the ability of the team to deliver better software faster will be noticeable. This will lead to having more time to innovate.