I’m sure many people new to the industry will be asking themselves; what is DevOps and do I need it? These are good questions, because at the end of the day the main goal for digital businesses is to deliver their services. So why concentrate on anything else that isn’t writing code and getting your applications out the door as quickly as possible to beat your competitors?
Well…DevOps will get your code out the door as quickly as possible all whilst making the delivery process automated, reliable and secure.
Let’s start by giving an example of a company not using DevOps to deliver their code…
A development team build their applications through a manual process on their machines and perform some functional testing before it is given to an operations team to deploy to a test environment. The test environment is always on and waiting for a release, the deployment is made and the test team is notified that the environment is ready, where they begin running their regression test packs and non-functional testing. Once the test team has signed off the release, the operations team then deploy it to Production through another manual process whilst also (hopefully) getting some kind of handover with the development team on how to support the new features. When an incident occurs, the operations team look into the issue, using the handover material try to diagnose the problem – the development team are hard to contact and get support from because they are developing the next release and aren’t really concerned with operations.
If this sounds familiar, then maybe your company should look at moving to a DevOps model…
First off, no amount of money, resource or tooling you throw at the problem will make your teams ‘DevOps’. For example, buying a license for a new DevOps CI server and asking the development team to automate their builds will fix the issue. As corny as it sounds, DevOps is more of a culture change.
A DevOps culture is centred around merging the responsibilities between development and operations. The primary goal is to increase collaboration between these two functions and encourage an attitude of shared responsibility. It is this shared responsibility that focuses the developers on enhancing systems to be easier to support. Although the more interesting parts of a project are usually the development, by sharing the operations teams’ pain – developers begin to gain more insight into operations tasks such as deployments, monitoring and general maintenance of the system.
This encourages them to develop processes with the operations teams in mind, highlighting potential new avenues for enhancements. This shift in culture also discourages silos between development and operations and replaces traditional handovers or knowledge transfer sessions with ‘working together on a solution from the start’ – which is always a more efficient method of learning.
So how do we start implementing this culture change?
Well the first thing we can do is reorganise our teams into Delivery teams (often referred to as Scrum/Agile teams). We get the development team and infrastructure engineers (DevOps Engineers, or more recently SREs – Site Reliability Engineers) working together in the same team. Through each sprint of work (usually 2 weeks) a rota is maintained to focus on who in the team is on development duty and who is on operations – this means that developers actually carry out the operations tasks. The fact that developers will now be responsible for their own code when it hits production empowers them to think more about things like exception handling, alerting & monitoring, release processes and automation.
So now we have our new team, how do we empower them using DevOps processes?
CI
Put simply, continuous integration is the continual merging of code by developers into a single branch, where applications are built and tested through a series of automated pipelines.
This practice of repeatably committing small changes allows delivery teams to rapidly deliver code that is tested more frequently and provide a greater oversight of change between developers. The longer developers leave it to commit code, the more likely they are to have merge conflicts with other team members.
Tools often found in this area are GitHub, GitLab & BitBucket for source control and CI servers like Jenkins, Concourse and Drone.IO for building and executing tests.
CD
Continuous delivery is the automated deployment of new application builds to various environments, ensuring that the latest application build is always automatically available for testing. At one extreme there is the continuous deployment of applications to Production environments many times throughout a day, whilst a more traditional view is to batch deployments up into releases for regular Change Approval Boards (CABs) deployments.
Tools often found in this area include Jenkins, Concourse, Drone.IO & GitLab.
Automation
The key to enabling DevOps is maintaining simple & effective CI/CD pipelines that handle builds, tests, security and deployments across a wide range of applications. A lot of this boils down to making the processes as common as possible so existing applications can use them as well as any new onboarded services. An example might look like;
- Automatically kicking off a build when developers commit their code to source control,
- Running a series of automated tests against the build including vulnerability scanning,
- Automatically deploying the application to a test environment should it pass all tests,
- Notifying the developer of all the tasks that have been completed.
Other processes might include using the same process (CI/CD pipelines) to build, test and deploy your infrastructure as code. Just because you’re deploying infrastructure and not applications – it doesn’t mean that same IaC can’t go through the same automated, repeatable process.
Now all of this may seem like a lot of work…and some of it is. There is quite a bit of a hump in upfront expenditure of resources and time before any application code is delivered to an environment. However, once these pipelines are in place you can expect to see tremendous gains in terms of productivity and cost savings. Being able to quickly, reliably and securely deploy your latest builds with a click of a button will change the way your business delivers forever.
Let’s look back to our example of our business, but now having implemented DevOps…
The delivery team check in their latest code changes which automatically trigger a build. The application is built and tests are run automatically against the service – including security tests. On successfully passing all tests – a new test environment is automatically created where the the release is deployed to either a test environments (or in some companies straight to Production as they are so confident in their CI/CD pipelines). If an incident arises, the developers who actually wrote the code are there on hand to respond to the incident.
In our example above, all actions were automatically kicked off by simply committing some code to a repository. In this example,
- the build was automatically started as soon as code was committed,
- the tests were automated, reducing the time taken to test the service,
- a new environment was automatically provisioned using Infrastructure as Code to exactly mirror production specification so any further testing is representative – the environment will be destroyed to save costs once it is no longer needed,
- the deployment was automated, reducing the risk of human error and greatly reducing deployment time,
- Developers were notified via Slack that their build had passed and was ready to use in environment X
To sum up DevOps, it’s about rapidly increasing development velocity whilst having absolute confidence in your infrastructure and applications. This enables your business to quickly prototype and become extremely agile whilst operating in an automated, secure environment.
Need some pointers? We provide DevOps Consulting Services to businesses in the UK and further afield. We would love to hear from you.
