4 Advantages of DevOps and CI/CD Pipelines


DevOps is a pretty broad term with plenty of tech­ni­cal jar­gon as­so­ci­ated. For the non-tech­ni­cal, un­der­stand­ing what DevOps is and how it im­pacts their pro­ject can be a bit over­whelm­ing. That’s why we felt it was im­por­tant to break down the ba­sic de­f­i­n­i­tions and ter­mi­nol­ogy as­so­ci­ated with DevOps and ex­plore the ad­van­tages that can be felt from in­vest­ing in prac­tices like a CI/CD pipeline.

What is DevOps?

First things first, the name DevOps is a mashup of Development and Operations. It pri­mar­ily re­lates to the stage be­tween those two ar­eas.

Every de­f­i­n­i­tion of DevOps dif­fers slightly, so here’s our vari­a­tion. DevOps is the use of tools, processes and peo­ple to im­prove an or­gan­i­sa­tion’s abil­ity to de­liver dig­i­tal prod­ucts and ser­vices at a high ve­loc­ity.

Yes, that is a very broad de­f­i­n­i­tion - this is 100% de­lib­er­ate.

There is so much in­no­va­tion and im­prove­ment in soft­ware de­vel­op­ment that it’s eas­ier to group some of these un­der a com­mon ban­ner.

One of the most com­mon ex­am­ples used when re­fer­ring to DevOps is Continuous Integration/Continuous Deployment pipelines (CI/CD).

DevOps cycle within a software development agency

What is Continuous Integration/Continuous Deployment?

One of the most fre­quent acronyms within the DevOps space is CI/CD. CI stands for Continuous Integration which is the prac­tice of merg­ing all code changes into a cen­tral repos­i­tory where a pipeline val­i­dates those changes through tests and builds.

CD could stand for Continuous Delivery or Continuous Deployment — they are sim­i­lar con­cepts but dif­fer on their ex­tent. Once a process meets Continuous Deployment, every time a code change is merged into the cen­tral repos­i­tory, it runs it through the re­lease pipeline, per­form­ing all the nec­es­sary checks be­fore re­leas­ing into a live en­vi­ron­ment for your users.

With CI/CD the dreaded ‘release day’ is a thing of the past. Let’s take a look at what a re­lease day en­tails with­out CI/CD pipelines. Firstly, test re­ports need to be cre­ated be­fore any re­lease can pro­ceed. These test re­ports need to be run on every de­vice, mean­ing there are a few de­ploys in­volved. Once these are cre­ated, the ap­pli­ca­tion still needs to pass a set of vig­or­ous man­ual ap­provals from DevOps spe­cial­ists. Again, this can be a timely pro­ce­dure, es­pe­cially if the DevOps spe­cial­ists are pre-oc­cu­pied with an­other re­lease.

With CI/CD these time-con­sum­ing pro­ce­dures are gone, mean­ing re­leases are fre­quent and test­ing is pri­ori­tised. We’ve bro­ken down the ad­van­tages that flow on from DevOps and in par­tic­u­lar CI/CD pipelines be­low.

4 Advantages of DevOps and Release Pipelines

1. Automation re­duces risk

Creating an au­to­mated re­lease pipeline sig­nif­i­cantly re­duces risk. Manual re­leases are not only time pro­hib­i­tive, but they can also be er­ror-prone. Consider a step-by-step process in your every­day life — how many times have you missed a step and had to go back and fix it? Cooking is a great ex­am­ple. I can’t count the num­ber of times I’ve had to wait 10 min­utes be­cause I’ve for­got­ten to pre-heat the oven. The more we can au­to­mate, the lower the risk of man­ual er­rors. This means de­vel­op­ers can fo­cus on the truly com­plex and cre­ative chal­lenges.

2. Improves ef­fi­ciency and re­duces costs

Depending on the en­vi­ron­ment, a man­ual re­lease can take on av­er­age 4-8 hours to com­plete. This is pre­dom­i­nantly due to all the man­ual checks and bal­ances that have to be per­formed by a de­vel­oper to en­sure the ap­pli­ca­tion is work­ing as ex­pected. With an au­to­mated re­lease pipeline that does most of that heavy lift­ing, ap­pli­ca­tion re­leases can be done in min­utes not hours, and can be done while the de­vel­op­ment team con­tin­ues work­ing. If a typ­i­cal pro­ject is re­leased fort­nightly at a min­i­mum and you’re sav­ing ~6 hours every time, it does­n’t take long for the in­vest­ment in DevOps to pay for it­self.

3. Emphasises qual­ity as­sur­ance

With test­ing and QA con­trols built into the re­lease process, the frame­work for suc­cess has been set and must be fol­lowed. This means au­to­mated, con­sis­tent, and in­stant feed­back on fea­ture qual­ity with test au­toma­tion. The key ben­e­fits are two-fold, firstly, you don’t have to wait for user ac­cep­tance test­ing or smoke test­ing to quickly de­ter­mine whether a fea­ture will break/​im­pact other fea­tures. Secondly, you can in­stantly view a fea­ture on your en­vi­ron­ment. Sharing this link means you can cross-de­vice test with ease.

4. Empower your team to do more

Specialist DevOps en­gi­neers are a dime a dozen. A com­pre­hen­sive pipeline means there is no need for spe­cial­ist DevOps en­gi­neers to be in­volved at every point of the re­lease process, em­pow­er­ing the ap­pli­ca­tion de­vel­op­ers on the pro­ject to han­dle more.

What has WorkingMouse done to lever­age DevOps?

Clearly we’re sold on DevOps, so we’ve taken a few steps to im­prove our ca­pa­bil­i­ties and lever­age more tools.

1. Update from Gitlab v.11 to Gitlab v.14

Some of the best DevOps tools have only re­cently been re­leased. Gitlab ver­sion 14 was re­leased in June this year and most im­por­tantly, it has a num­ber of pipeline au­toma­tion fea­tures that will level-up our in­ter­nal ca­pa­bil­i­ties. This has un­locked some of the ben­e­fits be­low.

2. Build out CI/CD pipelines

With the right tools at our dis­posal, it’s time to start lever­ag­ing fea­tures. Some of the ini­tial wins in build­ing out the CI/CD pipelines are pro­vided be­low. This is where it gets a lit­tle more tech­ni­cal, but we’ll do our best to break it down.

Gitlab pipeline view

This is the view of a Merge Request in GitLab, that utilised pipelines for test­ing, build­ing and re­view­ing apps. If you zoom in you can see that it gives the sta­tus of the last pipeline run, as well as the test sum­mary and link to the full test re­port. Importantly, it also dis­ables the abil­ity to merge (or re­lease your code into a new en­vi­ron­ment) un­til the pipeline suc­ceeds.

Here’s an ex­am­ple of a test re­port.

All the stages and jobs in a pipeline are vi­su­alised in a few dif­fer­ent ways to as­sist in see­ing at a glance what the Pipeline is do­ing, and the dif­fer­ent jobs that de­pend on one-an­other. Apart from look­ing re­ally flash, it pro­vides a help­ful overview for de­vel­op­ers want­ing to un­der­stand the re­lease pipeline.

3. Create greater vis­i­bil­ity through more in­te­gra­tions

In or­der to com­mu­ni­cate the progress of the most re­cent merge re­quest to the de­vel­op­ers re­spon­si­ble as well as the wider pro­ject team, an in­te­gra­tion with WorkingMouse’s in­stant mes­sag­ing ap­pli­ca­tion (Mattermost) was utilised. This cre­ates au­to­mated up­dates from Gitlab to Mattermost that let the team know whether the re­lease failed (and if so, why) or suc­ceeded.

4. Deprecate ex­ist­ing au­toma­tion tools

Existing test au­toma­tion tools (like Jenkins for ex­am­ple) are be­ing re­tired. This is some­thing that hap­pens fre­quently in the tech in­dus­try - new, bet­ter tools that help you do more be­come avail­able. Moving off old au­toma­tion tools will be a phased ap­proach, with some pro­jects mov­ing to pipelines im­me­di­ately while oth­ers will slowly be tran­si­tioned across.

There are some ex­cit­ing ex­per­i­ments in progress and we’re look­ing for­ward to re­al­is­ing these ben­e­fits on our clients’ pro­jects in the very near fu­ture.

Discover Software


Yianni Stergou

Marketing en­thu­si­ast and FIFA ex­tra­or­di­naire

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion