Recently, I have seen the term "DevOps" being discussed at most CIO and CTO offices across federal agencies. While many technologists do understand what it means, many others are not so sure. It becomes even more challenging for non-technical people such as business users, management consultants, testers, PMO office and the likes to understand this term as they may not necessarily participate in development and maintenance of a software. So, I decided to write a few lines on my understanding of DevOps to explain it the readers.
Typically in a software project, there is a development team that is responsible for gathering requirements and developing the product as per the requirements. There is also an operations team (Information Technology) which is responsible for maintenance and deployment of the product. These teams usually work sequentially: the Operations team follows the Development team to release a product or part of it. Software projects usually apply either a waterfall approach or Agile methodologies to implement development of solutions. However, for the purposes of this blog, I am explaining DevOps and will focus on the Scrum Agile approach.
Scrum projects have sprint cycles that generally run in a period of 1 to 4 weeks (not limited to these), where requirements in the form of user stories are prioritized by a champion of business (namely Product Owner). User stories are assigned points according to the level of their complexity. The development team assigns points at sprint meetings facilitated by a Scrum Master, then the developers work on the user stories planned for a sprint to build a piece of the software. Developers also write unit test cases to test the functionality they built, in parallel with the testing team, which is responsible for writing manual and automated test cases. These test cases focus on the functionality developed for each user story belonging to the sprint. At the end of the sprint, based on the testing results, the Product Owner either (1) accepts user stories or (2) rejects them and places them in the product backlog for work in future sprints. This is a relatively brief explanation as to how a sprint team works. For readers to understand Agile in greater detail, I recommend the Agile blogs written by a fellow technologist, Vinay Katari; these blogs are posted here.
Figure 1: Typical Sprint Cycle
While the development team works on this iteratively by gathering feedback from customers and making changes to the product to meet new requirements, most Operation teams work on a different schedule: once the Development team prepares a minimum viable product for a release, the Operations team receives it to deploy and maintain. Often, this affects the sprint cycles of the Development team, as they must work on fixing build issues, deployment issues, and integration issues instead of working on the product. This becomes even more challenging when there are multipleSscrum teams working on different parts of the product. More frequent integrations and deployments are required by the Operations team, which can also be responsible for setting up environments for product deployment. Going through the SDLC process can take up to many weeks and sometimes months, resulting in a delay to the project schedules or results in products with reduced features.
All of the above challenges can be easily dealt with when we combine Development with Operations, hence the term DevOps. Let's discuss this in detail: while the sprint team is iteratively developing, they will be responsible for continuously delivering their code on a repository such as GitHub, SVN, or CVS. The testing team will be responsible for writing automated test scripts to test the product developed thus far through the current sprint, then pushing the scripts to the repository. Meanwhile, the Operations team will be responsible for creating a continuous integration continuous development (aka CICD) environment wherein the team builds a hook into the repository to watch for file changes and trigger a build. When the build is kicked off, it will run all the unit test cases delivered by the Development team and the automated test cases developed by the Testing team. If the test cases pass, the deployment scripts are kicked off to promote the code to the desired environment. Otherwise, previous code remains untouched and the errors are reported. Isn't that sweet? You develop and check in the code, then leave it up to the environment to do the rest for you.
Figure 2: DevOps cycle, found this figure online which summarizes my explanation
Jenkins, Travis-CI, Hudson, Bamboo are some of the tools that can be leveraged to achieve continuous integration and continuous deployment of the product. While this takes care of CICD, there is another requirement to build an environment for the product with a single click of a button. This can be easily achieved by coding your infrastructure -- yup, that's right let me repeat: coding your infrastructure. Fortunately, with frameworks and tools out there such as Chef, Puppet, Ansible, and Salt, we are able to write code in the language specified by these tools to customize and develop infrastructure for any software. Let me use Chef as an example: with Chef, you develop the code (which is called recipe) to meet your infrastructure requirements and then use these recipes to stand up your environment in either cloud or your own data center. Amazon OpsWorks is a cloud platform where Chef recipes can be used. Anytime you need a new environment, just click a button to use the custom recipe to stand up an environment for you, and if you need changes in the environment simply update your recipes to reflect that. That's it -- that solved our other problem too!
To summarize what I explained about DevOps so far: it is the combination of the Development team activities and Operation team activities formulating DevOps. The Development team delivers code and test cases which are continuously integrated, tested, and deployed by the CICD setup to be pushed to a desired environment. The Operation team now is much more relaxed, as it can schedule more frequent releases with well-tested code and can address infrastructure needs by simply changing the infrastructure code. This way, end users see a well-tested product frequently and can provide feedback for periodic enhancements or changes to the system. I intentionally left out the waterfall approach, as there is not much gained by implementing DevOps in this approach. Deployments occur at the end of the product development life cycle. However, for Agile products, I recommend considering DevOps as your software development method to see much better communication, collaboration, integration, and automation of the teams and products.