There are often different reasons why stakeholders seek to embrace the DevOps philosophy and choose to implement cloud delivery on their projects. However, there are symptoms you might learn that indicate a need for improving the process of delivering software. Here are a few:
- Manual Instructions
- Tribal Knowledge
- Different Tools Across Teams
Each is described in more detail here:
Some silo examples include separate teams with different managers for functional areas such as DBAs, operations, Test/QA, Configuration Management, Application Developers, Business Analysts and so on. In this siloed approach, communication is stifled and wait time on processes is large. This drastically increases the overall cycle time and results in teams batching changes and processes which leads to more complexity, errors and long release times.
Documentation that describes how to perform build, test, deploy and release processes. Often, these steps are incomplete, outdated or vague. Even if they are uncommonly complete, up to date and specific, manual instructions aren’t repeatable requiring the operator to perform the steps flawlessly every time. Moreover, running manual instructions introduces increased process time and increased wait time which – of course – increases the overall cycle time
Tribal knowledge refers to knowledge that is passed around from person to person. This knowledge is built up over time – often as a result of longevity. There are several problems with tribal knowledge – 1) there’s no canonical source of knowledge and 2) tribal knowledge doesn’t scale well. As a result, software delivery processes are performed differently each and every time which leads to inconsistent results, errors, etc.
Email often becomes the default communication for all things and software delivery processes are no exception. Once, I saw a 75-thread email in order to make one configuration change. The problem with email is that the information can be misinterpreted, transient and isn’t versioned. As with tribal knowledge, the information doesn’t get codified into a canonical representation of a repeatable action.
Different Tools Across Teams
Another symptom of an organization that needs DevOps is when you see different teams using different tools for the same activity. For example, maybe developers are manually provisioning environments whereas operations is using a collection of bash scripts to provision environments. What’s more there might be additional and/or different provisioning steps performed in latter stage environments by operations leading to environments that look and behave differently.
Some teams use their issue tracking system to assign software delivery tasks to different people and teams in the software systems lifecycle. This approach seeks to coordinate teams and tasks, but the activities aren’t codified and, therefore, aren’t repeatable which will inevitably lead to errors.
Meetings are introduced to get all team members “on the same page”. It’s often used as a result of miscommunication across organizational silos. While meetings can help align resources and activities, they don’t result in repeatable activities and a canonical definition for these software delivery activities.
These symptoms often lead to downstream errors (much later in process – which are more complex and costly), delays and bottlenecks as a result of long wait times and releasing less frequently.
Sometimes you might be the change agent at your company, so you might need to spend some time convincing others at your company to make changes to improve how teams deliver software. If this is the case, you’ll need to look for some of the signs of a potentially broken process that I mentioned previously.
That said, the best indicator is to analyze the overall and average cycle time. To do this, you might create a value-stream map (like the one you see here) that maps all the processes conducted by various teams in the software systems lifecycle from the time someone commits some code until the software is in production. In doing this, include the actual process time, along with the wait times. For example, process time is the actual time it takes to execute an activity – such as the actual time it takes to run a build or deploy the software. The wait time is the amount of time it sits in a queue waiting for something or someone to perform the process. For example, in a traditional software delivery lifecycle, after someone builds the software and uploads the distribution to a binary repository, it sits in a queue waiting for someone from say – Test or QA – to run through some manual and/or automated tests. This is the *wait* time. Add up all these activities to determine the overall cycle time for a project. Since the times can vary widely between software deliveries, you’ll want to provide several cycle time metrics: shortest, longest, median and average.
Often, there are two primary objectives of implementing cloud delivery in most companies. These two objectives are increasing/amplifying feedback loops and reducing the cycle time. When implementing cloud delivery (or continuous delivery, in general), you’re automating the creation of the complete software system. When applying good software development practices such as committing code at least once a day on the mainline, stopping the line when something breaks, writing tests for code and versioning everything, you’re better able to reduce cycle time and increase and amplify your team’s feedback loops.
Align benefits with motivation
There are often different reasons why stakeholders seek to embrace the DevOps philosophy and choose to implement cloud delivery on their projects. Sometimes, however, certain team members need to be convinced of how cloud delivery can help improve how they currently deliver software to users. So, the best approach is to get them to articulate their primary motivation and align this motivation with the benefits. “We want to get Chef a server to create environments” isn’t motivation. It’s a means to an end, not the end. It can take some work, but get your stakeholder to clearly describe the pain they’re seeking to reduce or eliminate.
While it’s easy to enumerate many benefits of cloud delivery, the one I’ve found to be the most effective is agility. To be able to release software based on business need is significant. You do this by reducing the cycle time so that it’s approaching zero and providing continual feedback to team members as often as possible.
The Continuous Delivery production line
The software system production line goes by many names including deployment production line and deployment pipeline. In this course, I’ll mainly be referring to is as a production line as I think the manufacturing production line is the most analogous to what’s happening. People often misinterpret this production line to just be another way to refer to its very distant ancestor: the build promotion model. Don’t be mislead by this. Some distinct features of the production line include:
- Every commit could potentially be released to users (if it passes all production line stages)
- All steps always move forward (i.e. left to right in the diagram), never back and forth between stages
- All steps are fully automated (with exception of exploratory and approval gates). Team members do not enter commands that increase wait time while there’s queued work
The purpose of this course is to understand how to establish this production line on AWS. Here’s an example of a pipeline (i.e. production line) from the Jenkins CI server.