As a Director of Engineering you need to know a thing or two about DevOps. You may need to hire for a DevOps position, select tools, or even help put DevOps in place. For certain, you will need to create the correct environment, processes, and changes to implement a successful DevOps. Let's get started by answering a few questions.
What is DevOps?
DevOps is a lot about automating the development, release, and operation processes. It also encompasses communication and collaboration between the business, the development team, IT, and operations. You can think about it as unifying around a collaborative thought, and that thought is how do we produce and deploy code in the best way possible.
When DevOps is at the top of their game, it facilitates a seamless flow of planning, building, testing, and deploying software for the company.
The Bucket Analogy
Here is an example of a system without DevOps. Think about features that are required to be built by the product team. These features could be considered as water held in a bucket. The product manager has filled her bucket with as many features as she can hold and she is looking for a way to empty her bucket into another person's bucket. Naturally, she finds an engineer and starts to pour her features into his bucket. If she finds that the particular engineer's bucket is overflowing, she may need to look for another engineer and see if she can fill up that persons bucket as well. Once the product manager's bucket is empty, she sits back and waits for someone to return a finished product in the form of the features she asked for.
Meanwhile the engineer works on the water in his bucket. While he works he may find that other leaders are also trying pour some of their water into his bucket. In an effort to fit these additional requirements into the bucket he may have to pour out some of the other features to make room. Finally, the build is ready and the engineer is aching to pour his bucket out into a tester's bucket.
The tester has already learned that if they delay at all in pouring their bucking into the deployment bucket that they will never have enough room for all the water that inevitably comes there way. So they quickly test the feature and either try to pour it back into the developer's bucket because there was a problem or they dump it into the deploy bucket.
The deploy person has an infinite size bucket and consequently he lets this bucket just fill up until a release date comes. At this point he he lets the built features flow into production and calls it a release.
The product manager is relieved that the features she requested have made it into production but she is equally worried that her features may have been contaminated with other water buckets or that attention to the detail for her features was not done. So she cautiously digs through the application hoping that everything is good.
Does this analogy ring true for anyone? I have seen plenty of shops that work by this model. Even if the teams are following a Scrum methodology, this behavior can still creep in.
A Pipe
We can see the problems with everyone holding a bucket that gets filled and poured out constantly. Instead let's consider what would the process look like if the development, testing, and deployment process looked more like a pipe instead of individual buckets. A pipe has a specific and measurable flow of water that will pass through at any given time. Imagine that on top of that pipe is a funnel and on the bottom of that pipe is a diffuser. The funnel ensures that anything entering the pipe is organized, prioritize and flows into the pipe at a steady rate. The diffuser takes that flow coming out of the pipe and spreads it across the appropriate locations.
With a pipe setup, we can consistently load the features into the pipe, consistently push contents through the pipe, and effectively take the results of the pipe and deploy them where they need to go. You may ask, so what is happening inside the pipe? In its simplest form, the pipe represents the development, testing and deployment processes. Engineers receive work at a constant rate and push builds to be tested at a rate expected by quality assurance, deployment also receives a regular cadence of releasable features that arrive organized and dedicated for specific changes in the product.
The DevOps Pipeline
DevOps is responsible for creating the pipe that keeps things collaborative, organized, and flowing. DevOps' job couldn't be more important. As this pipeline matures and we keep a flow moving through a good process, DevOps can introduce additional key features to the pipeline. For instance, the pipeline should also include the following:
Continuous integration (known as CI).
Continuous testing (Unit tests written in TDD, and automated tests including regression testing)
Continuous delivery (known as CD)
Continuous monitoring
In many ways the DevOps team must advocate for each feature of the pipeline to be included. They are the champions of good process and keeping things flowing smoothly.
What are some prerequisites for DevOps implementation?
I recommend that before you jump headlong into a DevOps investment, that you consider these prerequisites:
Get commitment at the senior level of the organization.
Also communicate and get commitment for this change needed across the entire organization. A DevOps pipeline requires commitment across various departments like Product, Support, Sales, Marketing, Engineering, and IT. Remember DevOps is the union of people, process, and technology to continually provide value to our customers.
Understand the business goals and align the DevOps with these goals.
Ensure there is a strong SDLC and Agile process being followed that DevOps can automate.
Code should be in a version control software.
Invest in some automated tools for agile process compliance, automated testing, and automated deployment.
What are some best practices for DevOps?
DevOps should be a strong champion for communication and collaboration between development and operations.
DevOps is not successful without CI/CD practices.
The Ops team needs to ensure that the applications are working well at all appropriate levels. Monitoring tools will need to be in place.
DevOps should work with the development teams to build any tools that would help with the monitoring capabilities into the applications.
Always encourage feedback from end-users to enable continuous improvement that will help improve the process and help you deliver high quality software.
What are some DevOps tools to consider?
Jira (issue tracking and project management)
GIT / SVN / BitBucket (version source control)
Jenkins (automation server)
SonarQube (continuous inspection of code quality)
Docker (virtualize software packages as containers)
Chef / Puppet / Ansible (cloud provisioning, deployment, parity, and management)
Nagios / Splunk / New Relic (monitoring and alerting)
Understand the 4 C's
As a leader you should understand the principles of the four continuous needs for a DevOps pipeline.
Continuous Integration (CI) - Developers work on a feature within a sprint and commit their changes to the version control repository. CI is the process of automating the build and testing of code every time a team member commits these changes to version control. Committing code triggers this automated build where the system grabs the latest code from the repository and builds, tests, and validates the full master branch. This keeps the master branch clean.
Continuous Delivery (CD) - Delivery is an extension of continuous integrations which primarily gets the features that the developers build out to the end-users as soon as possible. This stage utilizes the continuous testing and various stages of quality assurance before it is delivered to the production system. In short, CD is the ability to get changes of all types prepared for deployment to production safely, quickly and in a sustainable way.
Continuous Testing (CT) - Tests that can be performed in an automated way should be generated and added to the pipeline. CT is the process of executing these automated tests as part of the software delivery process to obtain immediate feedback on business risks associated with software release candidates.
Continuous Monitoring (CM) - Detecting compliance and risk issues in your environment is important. Controls should be put in place to address these risks in production. CM can identify weak or poorly designed processes and components quickly and increase the effectiveness after each deployment.
Are you ready for Continuous Deployment?
The difference between Continuous Delivery and Continuous Deployment rests in how features are ultimately released to production. Many processes require certain customer scenarios and priorities to be considered before a feature is deployed to the users. In this case, features would not all be deployed automatically but would be deployed manually using tools. If your business scenarios do not depend on manual evaluation before deployment then the DevOps pipeline can instead be configured to continuously deploy completed features as they pass the testing phase in an automated way.
What roles to consider for DevOps?
There are a couple of positions to consider when directing DevOps.
DevOps Architect or Manager: This is the leader who is responsible for the entire DevOps process.
DevOps Engineer: This is the person who has the skills in coding and scripting who can setup the automation tools. They would be experienced with Agile, Version Control, CI / CD, automated testing, and setting up tools.
What are some Metrics or KPIs for DevOps?
DevOps is part of the SDLC process defined in the 360 degree SDLC model. As such, there should be some metrics that can be produced and communicated that help inform on the progress of DevOps implementation and help continuously improve on its state. Here are some metrics that should be considered:
Speed of Delivery - the time it takes for any work item to get into the production environment.
Deployment Failures - deployments don't usually fail but it is important to keep track of when they do and ensure that any mechanisms to roll back to a stable version are also working.
Escaped Defects - The count of any bugs after a deployment experienced by a customer.
Unit Test Failures - Unit tests are key to functional testing based on code changes. This measures how often these tests brake and to what extent.
Mean Time to Recover (MTTR) - This is the measure of the average time it takes to recover in case of a failure in production. This time should be very short and requires that proper monitoring tools alert these conditions quickly.
Product Performance - There are key performance metrics that should be determined
specific to the product.
Summary
DevOps is the unifying of development, product, and support around business goals. This unification defines a set of practices that automate the processes for software development between engineers and IT. The goal is to build, test, deliver, and deploy software faster, consistently, and reliably. DevOps builds a culture of collaboration among teams and employ the proper tools to make it happen.
Take care and go do something amazing today!
Comments