Skip to main content

TechBlog Archives - Mitra Innovation

Understanding DevOps

By Blogs

– Part of our Discover DevOps series, with Anuradha Prasanna

DevOps evolved from a rising demand for digital solutions, starting around 2010 and becoming mainstream in 2015.

DORA DevOps Maturity Quadrant

I remember as a junior engineer how we initially ran the software development and operations cycle in a waterfall fashion, with lengthy lead times to delivery, shifting to agile after a few years as the need for a faster software delivery cycle grew. DevOps arrived as a ‘big bang’ in 2015, allowing software features to be written and released faster.

But that’s enough of the history!


To most people DevOps means Continuous Implementation and Continuous Development (CI/CD), and that is indeed what drives DevOps in an organisation when established properly. But there are other elements required for the DevOps journey to become sustainable and cohesive within an IT organisation in the longer run. We can categorise these into three key areas:

  1. Processes
  2. People
  3. Culture

These three key elements must maintain a healthy environment for the CI/CD to run effectively and deliver business value to our software application customers.

Processes must be simple, supportive, effective and geared around agile planning and delivery to dynamically prioritise and manoeuvre software development towards fulfilling customer demands.

In addition, people must be agile and customer focused, with complementary skillsets to deliver real value to the customer while achieving rapid delivery.

The organisation, business units and team culture should support this by maintaining a healthy environment with boundary-free communications and the freedom and empowerment to innovate. Building teams, recognising their excellence and providing strong, supportive leadership is crucial.

DevOps teams act as one to achieve common goals, and that is to deliver fully functional software and features to the customer, faster!

With organisational processes designed with this objective in mind and teams built and led to succeed, this concept and the IT culture behind it becomes an enabler for all, making CI/CD effective in:

  1. Planning and prioritising the business requirements to be implemented
  2. Implementing business features in an agile manner
  3. Automatically testing the new features and resolving any issues
  4. Automatic deployment based on quality gates being passed
  5. Monitoring and gathering live health statistics
  6. Fewer issues in the live environment
  7. Bottlenecks and bugs found are prioritised and reported back to the requirements and planning process

Below shows a high-level list of items that must be leveraged by the CI/CD process:

  • Automated application deployment and promotion to next environments
  • Integrated automated testing in all deployment environments
  • Utilisation of test virtualisation (mock services and mock data) to shift-left testing
  • Orchestration of complex deployments for applications that span platforms (data, mobile, backend, middleware)
  • Manage slow-paced and fast-paced deployment dependencies (2 Speed IT)
  • Write the CI/CD pipelines as code (PaC)
  • Automated infrastructure management and provisioning with infrastructure as code (IaC)

In summary, this means development of high-quality software that works in production can be delivered to the customer faster than before. The effectiveness of the delivered software can be validated quickly, with a rapid turnaround for any course corrections.

Anuradha Prasanna
Enterprise architect | Mitra Innovation

DORA Quadrant for DevOps

DORA Quadrant for DevOps

By Blogs

Anuradha Prasanna, Enterprise architect | Mitra Innovation
– Part of our Discover DevOps series

DevOps Research and Assessment or DORA is a research program that investigates the capabilities that drive software delivery performance and stability in organisations across the globe. One of the useful analytical tools DORA provides is the DORA Quadrant. This tool determines the DevOps maturity of an organisation.

DORA DevOps Maturity Quadrant

The DORA Quadrant uses four key measurements:

1. Deployment Frequency

For the primary application or service that you work on, how often does your organisation deploy code to production or release it to end-users?


2. Lead Time for Changes

For the primary application or service that you work on, what is the lead time for changes i.e., how long does it take to go from code being committed to code successfully running in production?


3. Time to Restore Service

For the primary application or service that you work on, how long does it generally take to restore service when an incident that impacts users occurs i.e., an unplanned outage or service impairment?


4. Change Failure Rate

For the primary application or service that you work on, what percentage of changes to production or releases to users, result in a service impairment or outage, subsequently requiring remediation, e.g., a hotfix, rollback, fix forward or patch?


DevOps Performance
| by Deployment frequency and Lead time for changes


Application Stability
| by Time to restore service and Change failure rate


So, based on the deployment frequency and the lead time for changes, we can determine how effectively DevOps is performing, and by looking at the time to restore and the change failure rate, we can understand the stability of the application. 

Using DORA you can also compare your application or organisation with their annual, global studies. 

You can see here a summary of the study DORA has done in 2019:

source: DORA Accelerate State of DevOps 2019 report

Source: DORA Accelerate State of DevOps 2019 report

By comparing your application/team/organisation’s rating to these industry benchmarks, you can get a clear understanding of how you are performing.

If you have multiple applications to assess, you can measure these individually deriving an average for the final quadrant.

In summary, the key measurements above allow you to apply industry recognised metrics to your application development and deployment, assessing the quality of your application code and the maturity of your DevOps process.

This is a great tool for any organisation to assess current development and deployment processes and track performance against set internal targets and those of the industry.


Get in touch with us

To learn how Mitra Innovation Experts can help you, call us for a free consult at
0203 908 1977 or email us at We look forward to hearing from you.

CI - CD Automation with Jenkins

CI - CD Automation with Jenkins

By Blogs

Software teams face a dilemma when they move away from traditional waterfall methods to agile methods of software development. Waterfall methods mean that software teams are required to iteratively build and integrate entire lists of system components and ensure that the components are tested well.

Even though waterfall methods are a manual process, it can be handled with fewer complexities due to the lower rate of iterative cycles.

With agile methods in play, teams follow a continuous – build, integrate and test – roadmap to continuously expand system functionalities instead of simply building components separately and assembling them together at the end.

Understanding Continuous Integration (CI) –

Multiple engineers work to develop new systems one component at a time. Every time a new component or feature is completed, the finished component will be added to the existing code. This is what is referred to as a ‘build’.

For instance, consider the following example;

A movie production team creates an initial video clip and completes the whole sequence by continuously adding new frames. Everytime a new sequence of frames are added, the producers play the movie from the beginning to check whether the whole movie still makes sense. If it does, then we can safely say, we do have a ‘green build’.

Now, let’s say an engineer adds a new piece of code to the green build. However, when the test is run (just like re-running the whole movie sequence), it turns out that the new component doesn’t fit in very well. The component doesn’t integrate and thus results in a ‘red build’. Now, the engineer who created that particular faulty piece of code has to fix it.

Previously engineers wouldn’t have wanted everyone to know that a faulty piece of code had been added to the system build. Today, however, it is the opposite.

Thanks to Continuous Integration practices the development team is informed as soon as a faulty piece of code is added to the build. Developers make use of ‘red’ and ‘green lights’ to maintain build status visibility across the team.

A red light indicates that no new piece of code is to be added until a green light is indicated.


In the case of the above example, let’s assume the team consists of 10 developers. A team of 10 developers will be adding or changing code at a rate of 50 times a day per developer. This adds up to nearly 500 builds per day, per project. This will also include the following activities for each day the project is in development:

  • 500 rounds of source code downloads
  • 500 rounds of source code compilations
  • 500 rounds of artefact deployment
  • 500 rounds of testing (i.e unit testing, regression testing)
  • 500 rounds of build pass/fail notifications

This is a point where automation is called to task.


Understanding Continuous Deployment/Continuous Delivery (CD) –

CD is abbreviated for both; Continuous Deployment and Continuous Delivery. It must be emphasised that the two expansions of CD are mutually exclusive and do not mean the same thing.

Allow me to elaborate in the following example;

There are two types of television programs; the news, and a cookery show. Unlike the cookery show, the news program will have to go through a considerable number of checks prior to broadcast. Similarly, certain software domains accommodate the freedom to perform a direct release into production environments, whereas other software domains are required to make a business decision (prior approval) in order to proceed with a release into production environment.


Continuous deployment and continuous delivery both mean automating deployment and testing of a software on a regular basis to a production-like environment. However, the differences are as follows:

Continuous Deployment  —  A process which is fully automated and includes production deployments (no human interaction after code – commit).

Continuous Delivery  —  An almost fully automated process where production deployments occur with a business decision.


When following CI-CD methodologies, a pipeline typically breaks the software delivery process in to various stages. The last stage will provide feedback to the development team. Even though there isn’t a defined standard for creating a pipeline, we are able to identify the following stages:

  • Build automation
  • Continuous integration
  • Deployment automation
  • Test automation

A project may have different pipelines or even different types of pipelines for different purposes.

Let’s take a look at our options.

This leaves us with a requirement for a powerful tool which is capable of the following, using pipelines:

  • Automate code builds
  • Build artefacts
  • Perform deployments
  • Run tests
  • Provision above into multiple environments (Dev, SIT, UAT/ Prep/ Prod)

This leads us to several different engines such as:

  • CircleCI
  • Eclipse Hudson
  • GitLab CI
  • JetBrains TeamCity
  • ThoughtWorks GoCD
  • ThoughtWorks Snap
  • Jenkins

Jenkins –

Jenkins is an open CI-CD tool written using Java programming language. Since Java is platform independent, Jenkins inherits the same and will run on most platforms available today.

Jenkins commenced as a fork off the original Hudson project and has evolved since day one. Today it is among the top contenders in DevOps tool-chains because it is free, open source and modular.

Even though the functionalities of Jenkins – straight out of the box – is very limited, there are more than 1,000 plugins which enhance capabilities of Jenkins far ahead of most commercial or Foss tools.

Jenkins interface

(Jenkins interface)

Coming back to the original idea of choosing the CI-CD tool for our software projects here are some ways in which Jenkins can match our requirements,

  • Automate code checkouts from repository
    • Supports almost all of the existing source code repositories and can expect to support upcoming ones as well (i.e: Mercurial, Subversion, Git, CVS, Perforce, Bzr, Gerrit, Monotone, Darcs, etc.)
  • Automate the build
    • Supports most of the build automation tools available (i.e: Command-line, Maven, Ant, Gradle, etc.)
  • Every commit should build on an integration machine
    • Supports by polling as well as providing listeners to trigger builds by the SCM (i.e: Poll SCM feature, Git Hooks, etc.)
  • Make the build self-testing
    • Supports most of the unit testing tools/platforms through number of plugins (i.e: JUnit, NUnit, etc.)
  • Test in a clone of the production environment
    • Supports most of the test tools/platforms through number of plugins (i.e: JMeter, SoapUI, Selenium, Cucumber, etc.).
  • Make it easy for anyone to get the latest executable version
    • Supports by maintaining build execution history and through number of plugins (i.e Build history, Version Number Plugin, etc.).
  • Everyone can see what’s happening
    • Supports through the simplest easy-to-understand UI and build statues (i.e: Green, Red, Gray build statues, Blue Ocean project, etc.).
  • Automate deployment
    • Supports automation as out of the box product, build pipelines and variety of plugins (i.e: Cron Jobs, Build pipeline plugin, etc)


Conclusion –

It is not easy to emphasise enough on the importance of orchestrating, automating and streamlining development processes. Deployments themselves being tested over and over will provide for almost complete confidence in the system being built.

CI-CD is central to DevOPs, and a successful DevOps implementation may contain implications that extend beyond IT and to business itself. Continuous improvements of software continuously improves products and services.