Making Sense of DevOpsYour Executive Roadmap to the New Era of Software Development

ebook

2

Introduction

What is DevOps?

How DevOps Works

6 DevOps Best Practices

The Business Value of DevOps

How to Transition to DevOps

Draw Your Current Value Chain and Flow

Make Sense of the Key Metrics

Look Into a New Toolkit

How to Assess Your DevOps Performance

Moving Forward With DevOps

About Infopulse

3

4

5

8

14

16

17

18

19

21

24

25

Contents

3

Amazon could deploy new software to production every 11.6 seconds in 2011 1. Today, their deployment frequency is even higher and has nothing to do with the company’s size or budgets.

Amazon has been among the early adepts and eager supporters of the DevOps movement – the new reality of software development.

Like Ford’s assembly line propelled the manufacturing industry into the new era, DevOps culture is changing the speed, quality and agility of technological production.

1 Velocity 2011: Jon Jenkins, “Velocity Culture”

4

What is DevOps? DevOps is a set of practices that promote better collaboration and

higher automatization of the processes between operational and

development teams. Though, the practices can be extended to other

business units.

“Dev” is an abbreviation for developers, QA, Product and other teams

involved in shipping the product. “Ops” is a blanket term for operational

professionals – system engineers, administrators, release and network

engineers, security staff and other job titles.

DevOps essential practices are geared towards eliminating the “ping-pong”

between these two departments through establishing new communication

processes, fostering tighter collaboration, smoother integration and

automation of low-value processes. It’s a shift in mindset aimed at breaking

the “silo” between the two teams and merging them in one, effective unit that

can ship new products faster with fewer people involved and less hours spent.

• DevOps is a cultural philosophy that assumes new methods of collaboration between different departments.

• DevOps is a set of best practices that help teams build, test and deploy new software faster and with less bugs.

• DevOps assumes using new tools for automating zero-value business processes and eliminating ineffective, manual routines.

DevOps stimulates the adoption of new practices that are continuous in nature and enable flow, small batch size deliverables and continuous improvement to software development process and ultimately, the product itself.

Embracing DevOps means that your organization is ready to create an ongoing, cross-department conversation about strengthening the current business processes, introducing new practices and actively preaching increased collaboration, knowledge sharing and experimentation.

“DevOps is a culture, a movement, a philosophy”.

5

How DevOps Works

“Individuals and interactions over processes over tools. Working systems over comprehensive documentation. Customer and developer collaboration over contract negotiation. Responding to change over following a plan”.

DevOps Manifesto by Ernest Muelle

Learn More

6How DevOps Works

The DevOps movement is deeply rooted with two approaches –

Agile and Lean.

Originally, development teams were strictly responsible for

building the product only, while the “Ops” personnel was in charge

of dealing with “whatever will happen next”. Agile software

development practices were geared towards reducing this gap

and introduced an incremental approach to project planning.

Work became prioritized based on business and customer value.

Development teams were encouraged to closely collaborate with

the customers and other teams. Cross-functional teams became

in charge of working over a certain product feature over a fixed

period of time.

DevOps movement pushed agile practices one step further – and

extended the usage of Agile principles beyond “the coding” to the

entire delivery lifecycle.

Under the DevOps philosophy teams:

• embrace new approaches to automating low-value, slow and

manual processes whenever possible;

• aim to release early and often;

• have a set of specific KPIs and carefully measure the success of

each new change;

• operate under the principle of “Quality is not something you tack

on the end.”

The goal of DevOps is to increase the teams’ velocity, acceptance

and rapid response to change and a help them develop a razor-

sharp focus on the value generated by each action.

DevOps is based on the concept of a value stream. It represents

for all the steps required to create and deliver something of value

(feature, product) to the consumer.

Within traditional companies all the value streams are usually

fragmented into three phases:

• Strategy – ideation and creating a basic list of requirements for

the brainstormed features.

• Development – writing the code, testing and debugging new

add-ons.

• Delivery – scheduling the final release, gathering user feedback etc.

Different teams are held responsible for specific KPIs and tasks at

each stage. The project information is only exchanged partially and

is not fully integrated with the rest of the value stream. Developers,

operations and strategy teams use different tools and do not

always pass on all the required knowledge to the other teams.

DevOps assumes the switch to a unified value stream. This

means merging all the people, tools, processes and information

exchanges in a single “source of truth”. All staff involved in

delivery of the software should have seamless access to

information and insights required for decision making.

7

The creation of unified value streams assumes following the next three principles of DevOps:

The First Way facilitates a fast left-to-right flow of work from Development to Operations to the customer. All the work is visible, and broken into small-size tasks, performed in specific intervals.

The goal here is threefold:

• Eliminate the possibility of passing a known bug to another team (Ops).

• Constantly seek new ways to improve existing workflows and further eliminate frictions.

• Never allow local optimization (or problem) to grow into a global failure.

The Second Way encourages the creation of a constant feedback loop from right-to-left at all stages of the value stream.

The key outcomes here are as follows:

• Develop a better understanding of all customers and users (internal and external).

• Amplify the feedback loops, so that problems are detected and recovered from faster.

• Embed new knowledge where needed, so that it enables product owners to build a system where problems are discovered and fixed before a major failure occurs.

The Third Way assumes the creation of a high-trust culture, encouraging continuous experimentation and improvement of current best practices; a scientific approach to risk-taking, so that the teams learn both from successes and failures.

The positive outcomes of the Third Way are:

• A working environment that encourages teams to experiment and take risks, which in turn helps them learn faster compared to the competition and dominate the market.

• The effects of new knowledge are multiplied. Local discoveries can be easily transformed into global improvements.

• Anyone within the company can access and benefit from the cumulative experience of everyone else.

These three principles constitute the base of a mature DevOps culture and backed-up by the DevOps best practices described in the next chapter.

Three Principles Underpinning DevOps

Business Customer

Dev Ops

OpsDev

OpsDev

How DevOps Works

Source: https://dick1stark.com/2016/11/08/the-devops-handbook/

8

6 DevOps Best Practices

The principles mentioned in the previous sections should be backed by

respective practices, promoting faster software development; increased

code quality; active knowledge exchanges and collaboration.

DevOps is a culture and it must be continuously nurtured by introducing

respective best practices.

1. Continuous Delivery

Continuous delivery is a software development practice that enables

product owners to ship product changes at any stage without hampering

the product performance, quality or user experience.

All the new code changes are built, tested and prepared for a release

automatically to the production-like environment from system/

application configuration stored in the version control. Deployment

to production can occur manually or automatically depending on the

business needs.

Continuous delivery enables businesses to release new features; fix bugs

or make any server-side configuration changes in the background without

compromising the product’s performance.

Learn More

“DevOps is a tool-centric philosophy that supports a continuous delivery value chain.”

96 DevOps Best Practices

The goal of continuous delivery is to have the code available in a

deployable state at any given timeframe. The project itself may

be half-boiled, but the proposed new features are already vetted,

tested, debugged and ready for deployment whenever needed.

At Infopulse, the continuous delivery framework operates in the

following manner:

• Core tasks are broken down into small-size updates by the

developers. Originally made in version control, those updates

will be deployed to production-like environment once complete.

• After the new code is committed, the team receives instant

feedback from a series of automated test cases (acceptance

testing, performance testing, regression testing, security

testings etc) deployed by respective tools.

• If an automated test fails for some reason, the responsible

developer will manually look into the case and make fixes.

• Additional automated testing may be triggered if needed before

the final feature release.

The baseline principle of continuous delivery is that development

and testing are merged into one unified process. It is organically

integrated into the delivery workflow and speeds up the product

timeline while ensuring that quality standards are met.

Continuous delivery practice is often associated with continuous

deployment. The latter is a separate process that may (or may

not) be part of your workflow. Continuous deployment assumes

that every product change or update is deployed automatically to

production without any manual supervision from a DevOps engineer.

Continuous delivery practice does not incorporate automated

deployment. There is a technological capacity to deploy new

changes automatically, but the deployment can be scheduled

manually for respective business reasons.

Continuous Delivery vs. Continuous Deployment

Continuous Delivery Unit Test

Auto Auto Auto AutoManual

Platform Test Deliver to Staging Deploy to Production Post deploy testsApplication

Acceptance tests

Continuous Deployment Unit Test

Auto Auto Auto Auto Auto

Platform Test Deliver to Staging Deploy to Production Post deploy testsApplication

Acceptance tests

Source: https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff

106 DevOps Best Practices

Continuous integration is another optional practice of the continuous delivery framework. It assumes that all developers submit code to one central branch of the repository multiple times per day. The goal here is to maintain the most current version of the source code in one place so that each team member could review or pull from the latest code version to avoid any potential conflicts. Continuous integration reduces the time required to validate new updates; improves the software/code quality and helps locate and address bugs faster.

2. Microservices Architecture

A single application is no longer viewed as a monolith one. Microservices architecture practice breaks down the entire product into a set of small services and features. The design architecture is developed in a way that allows each service to run its own processes and interact with other services using lightweight mechanisms such as APIs (application programming interfaces).

The main idea is to decompose a large product into individual services that are tied to a single purpose. This way your product becomes more modular – each service can be understood, developed and tested independently without compromising the entire product. The overall architecture becomes resilient to erosion over time.

The key principles of microservices architecture are as follows:

• Each service is independently deployable; decentralized; built and released using automatic tools and processes.

• Services (or groups of services) are easy to replace or revoke if

needed.

• Services can be developed using different programming

languages, databases, software and hardware environments

depending on your current business needs.

• Services are grouped around certain use cases e.g. billing, front-

end, logistics etc.

A microservices-based architecture enables better agility and

allows businesses to scale their product effortlessly at a lower

cost and within a shorter time-frame. As part of the continuous

delivery framework, the microservice architecture allows to

deploy application changes by re-building and re-deploying only

one or a limited number of services.

3. Communication and Collaboration

DevOps culture bridges the divide between different teams

through increased collaboration, transparency and knowledge

exchange. The layering principle is that the same people who

develop an application should be involved in shipping and

running it.

Extensive usage of respective tools and automated delivery

processes already encourage tighter cooperation between the

two different entities (developers and operations). Merging

workflows and operations should not be the final point though.

11

DevOps culture is based on the pillars of sharing and active knowledge exchange. As the Third Way principle states – empower your teams with the right tools for continuous experimentation and lifelong learning. Strive to build an environment that maximizes knowledge sharing and encourages communication across different teams – developers, operations, marketing, sales, and even customer support. Every person in your organization should understand the overall business goals and align them with their project and task at hand.

Work towards creating and maintaining corporate wikis that would detail all product aspects and continuously communicate the current best practices, product values and project goals. Create documents that outline:

• Information Architecture: all user interfaces, wireframes, mockups and other UX materials.

• Design Specifications: brand colours, fonts, required dimensions, aesthetic factors and so on. Be as specific as you can.

• Product Description: key product features and requirements; overall product business logic and suggestions about the future features.

• Development Handbook includes information about all the key technology you are using, current architecture, quality assurance guidelines, key tools, overall software development lifecycle (SDLC).

If you are managing a distributed team or outsourcing part of your operations, leverage the next practices to boost knowledge exchange between in-house and remote personnel (see the diagram on the right).

Make it easy for everyone on the team to know what is happening at any given time.

How GSD Impacts Knowledge Sharing?

Global Softvare Development (GSD) Inhibitors

Relational Qualities to Promote E�ective Knowledge Sharing

Cultural Di�erence

Language Barriers

Safety

Fear to lose Knowledge

Need ofCollaborative Tools

Lack of Trustand Rapport

Temporal Distance

Lack of F2FInteraciton

Comm. MediaShortcomings

OrganizationalHierarchies

ContextualDi�erence

Lack of adequateKM System

Di�erent KnowledgeBackgrounds

Separation of Tasks(Information Silos)

How comfortableis it to Seek/Share

knowledge?

Engagement

Getting people actively participate

in knowledge Creation

Access

How to Access the knowledge su�cientlyand in Timely manner?

Knowledge

What to Share?Where to Find?

6 DevOps Best Practices

Source: https://malibabar.files.wordpress.com/2014/12/talkinbrazil-05august2014.pdf

12

4. Automated Infrastructure

Infrastructure as a code practice assumes that you have specific

scripts in place that can perform every step of infrastructure

creation including server propagation, OS installation,

configuration, and so on. Infrastructure is provisioned and

managed using code and with the help of version control and

continuous delivery techniques.

Infrastructure coordination should not be tied to a single machine

or cluster but can be copied and replicated for as many nodes

as needed. Different team members can alter and improve

the configurations through the development lifecycle using

standardized patterns.

Popular DevOps tools like Puppet and Chef can help you

orchestrate and fine-tune your setup by automatically generating

necessary scripts to support the Infrastructure as Code

workflows.

System administrators can further use code to automate

operating system and host configuration, standard operational

tasks and additional common processes. This reduces the number

of manual operations the staff has to perform, freeing their time

for more valuable tasks.

5. Chaos Engineering

The main idea of chaos engineering is that modern distributed

software applications must be prone to experiencing unexpected

turbulent conditions. Thus, such systems must be initially

designed to resist unexpected problem and weaknesses in

production environments.

Chaos engineering is based on four key principles that

development teams use for probing software system

weaknesses:

• Define a steady state – a certain measurable output of your

system that stands for normal behavior.

• Assume that this steady state will remain as it is both in the

control group and the experimental group.

• Add variables that will represent real-world events such as

server outages or crashes, hard drive malfunctioning, network

connection problems and so on.

• Attempt to disprove the initial hypothesis by searching for a

difference in steady state between the control group and the

experimental group.

Encourage your team to experiment with random failure of non-

critical services and system cases. The development team should

be tasked with creating fast automated responses for such cases,

gradually moving on from the non-critical services to the critical

services and a combo of different failures.

The goal of chaos engineering is simple – train your teams to build

architecture and systems that can automatically adapt to failures,

without hampering the core functionality of the software.

6 DevOps Best Practices

13

Netflix is identified as the pioneer of chaos engineering. The company started migrating their data centers to the cloud in 2008 and incorporated some degree of resiliency testing in production. Later, their in-house experiments grew into an open-source Chaos Monkey project – a tool that randomly selects groups of systems (services) and terminates one of the systems in that group. The “failure” is staged at controlled time and interval so that there is staff around to investigate the problem and the system performance.

By adding an element of failure to the mix, the Netflix team encouraged developers to create systems that could function autonomously in case of failure and create resilient design architecture from day one.

While chaos engineering is a trailblazing practice that allows creating robust systems, prone to many types of failures, the practice may not be suitable for organizations at early stages of DevOps adoption.

6. Transformational Leadership

DevOps fosters extensive organization-wide transformation that goes beyond the development and Ops teams. IT leadership will also need a major overhaul. By 2020, it is predicted that 50% of CIOs2 that have not transformed their capabilities will be removed from the digital leadership team.

Winning teams should be lead by engaged and transformational leaders – the ones capable to inspire and motivate others to do their best work through appealing to their core values and sense

of purpose. Transformational leaders should occupy both mid-level and senior positions to encourage wide-scale organizational change. Their main goal is to get their teams to identify with the organization/project they are working for and support the organization’s main business goals and objectives.

Other DevOps practices will fall flat in the long run without the active and constant support of the new leaders.

2 Gartner Predicts – IT Infrastructure & Operations.

6 DevOps Best Practices

14

The Business Value of DevOps

Increased frequency of deployments of our software/services

59%

58%

48%

45%

69%

34%

13%

23%

Improved quality and performance of our deployed applications

A reduction in time spent fixing and maintaining applications

Reduced time-to-market for our software/services

Increased collaboration between departments

A reduction in spending on development, testing, or operations

2018 2017

27%New software/services that would otherwise not be possible/explored

26%An increase in revenue

23%Increased numbers of customers using our software/services

Our software/services made available across more platforms

Fewer employees working on developing and deploying our software/services

38%

39%

30%

46%

39%

25%

12%

19%

19%

20%

18%

Benefits of DevOps

What benefits have you seen or do you anticipate seeing from implementing DevOps in your organization?

Note: Multiple responses allowed

Base: 128 respondents in 2018 and 237 in 2017 who have adopted or plan

to adopt DevOps principles

Learn More

Source: 2018 State of DevOps: Research Report by Interop ITX

15

DevOps enables companies to build more robust environments

for their products within a shorter time frame. High-performing

DevOps teams, when compared to low-performing peers or those

still to embrace the DevOps movement, manage to3:

• Deploy code 46 times more frequently

• Have 440 times faster lead time from commit to deploy

• Show 96 times faster recovery from downtime

• Have 5 times lower change failure rate (changes are 1/5 as likely

to fail).

The particular appeal of DevOps is that you no longer have to

trade speed (time-to-market; deployment frequency) for product

stability and vice versa. The DevOps framework assumes that

you gradually develop the capability to maintain both at a high

score by adopting continuous delivery and integration; shifting to

the microservices architecture, embracing an agile approach to

project management and experimenting with chaotic engineering.

DevOps comes with three specific groups of benefits for

businesses.

1. Technical Benefits:

• Less complex project management process.

• Faster problem resolution.

• Smoother and faster product life cycles with continuous delivery.

2. Cultural Benefits:

• Motivated, happier and more productive teams.

• Higher employee on the job engagement.

• Improved professional development opportunities and cross-

department knowledge exchange.

3. Business Benefits:

• Faster time-to-market for new products and features.

• More stable operating environment, resilient to failure.

• Improved cross-department collaboration and communication.

• More time to innovate and create new features for customers,

rather than focusing on maintenance and fixing known bugs.

The Business Value of DevOps

3 2017 State of DevOps Report by Puppet and Dora.

16

DevOps is not about solely adopting new tools for automating certain development and operational processes or applying “modern best practices” to patch the problematic areas. The key to success with DevOps is to embed its core principles in your company’s culture and relentlessly encourage their adoption and adherence by staff of all levels.

There’s no unified framework for “Doing DevOps The Right Way”, but rather a set of steps transitioning companies can take to facilitate the process.

Develop a Vision for Your DevOps Culture

To succeed, you need a clear business justification for embracing DevOps. The process will require a sit down with not just the development and operational teams you will want to merge, but with all business teams.

Take the time to understand the teams’ current needs, the common

struggles and pressing pain points that prevent them from operating at full

capacity. Optimization without a proper vector is useless. You will have to

define very specific objectives and measurements for success during your

vision development sessions.

The result of your sessions should be:

• Strong justification for implementing DevOps.

• The overall vision of how it will work for your company.

How to Transition to DevOps

17

Draw Your Current Value Chain and Flow

DevOps Сycle or The 6 Cs of DevOps

DevOps

CollaborativeCustomerFeedback

& Optimization

CollaborativeDevelopment

ContinuousTesting

ContinuousMonitoring

ContinuousRelease andDeployment

ContinuousBusinessPlanningEvery company has its internal drivers for creating certain value. It can be purely monetary reward,

social responsibility, industry leadership or any other positive outcome you are trying to achieve.

Each and every value is pinned to certain actions, performed by your staff and respective systems or tools. Investigate into these matters. Start with one business unit (the development team) or system (QA) and expand from there.

Look into how new features are currently developed, deployed, and then used by customers. Consider how you can make the entire process less wasteful – reduce zero-value processes, increase efficiency of individual actions and the cumulative team effort.

As a Product Owner, you should be asking the following questions:

1. What is our current process for this?

2. Why are we doing it this way?

3. How long does this action take on average?

4. What prevents you from doing it faster? What bottlenecks are you dealing with?

5. How long does it take to develop this feature and hand it to Ops?

Next, map existing processes and teams to the value chain and define the critical path towards your ultimate goals. See what obvious optimization routes are available. Repeat the same thought process for different teams and look for hidden and indirect opportunities for further optimization.

Source: https://dzone.com/articles/6-cs-of-devops-adoption

“Communications is a really big place to get started. Getting everyone educated. Developers need to be able to tell the ops team the big things that are coming. Ops will then be well aware that this is coming. Visibility is key here - much more visibility into what’s going on in a day to day basis”

Matt Bentle, Solutions Engineer at Docker

18

Establishing a set of key metrics is essential to have a clear understanding of your DevOps progress over time.

The baseline KPIs to track are as follows:

• Production failure rate: how often new software fails in production over a set period of time (6+ months).

• Average lead time: how long does it take to build, test, deliver and deploy a new requirement in production.

• Deployment speed: how long does it take to deploy a new product version to a particular environment (e.g. integration, staging, pre-production or product environment).

• Deployment frequency: how often can you deploy new releases to test, staging, pre-production and production environments?

• Mean time to recover: what is the average recovery time for an application after a failure?

• Mean time to production: how long does it take for a new code committed to a code repository to be deployed to production.

You may consider tracking other metrics, however, do not go after those that would look impressive on paper, but will not correspond with your value flows or business benefits.

Make Sense of the Key Metrics

19

Look Into a New Toolkit

Learn More

The tools you choose should support the value roadmap you have developed. They should complement your key processes, which in turn support your entire business systems, and match respective value flows.

Automation is the best solution for processes that are time-intensive, prone to error and inefficient at the moment. Your approach to automation should be standardized to ensure that all teams have a common frame of reference.

At a minimum, you should look into tools that will facilitate version control, build/deployment process, testing, change management and possibly Infrastructure as Code.

The ones we recommend are as follows:

• Code Management Tools: GitHub, Bitbucket, Gitlab.

• Build Tools: Gulp, Npm.

• Deployment Tools: Jenkins, Bamboo, Codeship.

• Testing Tools: Selenium, Appium, Sikuli, BrowserStack.

• Containers and Orchestration Tools: Docker, Kubernetes, Ansible, Chef, Puppet.

• Project Management Tools: Atlassian Jira, Confluence, CA Agile Central.

20Look Into a New Toolkit

DevOps Tools Ecosystem

Analysis Collaboration SCM CIRepo Mgmt Build Tools Functional Performance SV Deployment Config Mgmt Conteiners Cloud Release Monitoring UX BITest Data Mgmt

Capture& Tracking

01Plan

02Develop

03Test

04Release

05Operate

Source: https://www.blazemeter.com/blog/ultimate-devops-tools-ecosystem-tutorial-part-1

21

Whether you are just en route to adopting DevOps or have already incorporated certain practices, measuring DevOps performance is crucial to succeeding with the initiative in the long run.

As mentioned earlier, DevOps transformations when not underpinned by specific business drivers, can face a backlash from teams, who do not fully

share or understand the reason for transition. That is why everyone should be aware of the key success metrics and have a clear understanding of their role in achieving those.

How to Assess Your DevOps Performance

Learn More

22

Driver 1: Business Success

Products are valuable for the company when they generate

steady revenue, increase customer base, improve the brand

perception, reduce customer service costs and so on.

Each new piece of software pursues a certain goal and can

potentially influence either of the following KPIs:

• Average revenue per user.

• Overall recurring or incremental revenue.

• Customer lifetime value.

• Customer acquisition costs.

• Rate of customer churn.

• Conversion rates.

Knowing the exact goals of your product helps everyone on

your team to understand how their actions relate to the product

success. It also helps you prioritize certain features productions

over others and improve the overall decision-making process.

Driver 2: Customer Experience

Building a product aligned with your company’s business values

does not guarantee its success. If it does not delight the customer

and does not meet their expectations, that product is doomed to

failure.

Think Fitbit. In 2016, the company had to lay off 6% of their

workforce due to lower than anticipated revenues during the

holiday season. The new product line failed to meet the customer’s

expectations. The good news is, Fitbit was fast to recover from a

failure and paid more attention to customer experience KPIs.

For software products the metrics you should track are as follows:

• User growth rates.

• Average funnel/conversion rates.

• Amount of time spent interacting with a product/feature.

• Number of daily/weekly/monthly visits.

• Frequency of key transactions.

• Split test results.

• Overall customer satisfaction rating and direct feedback.

Driver 3: Product Performance

62% of users4 will immediately delete a mobile app if it froze,

crashed or displayed an error. And only 16% will give a glitching

app a second chance for recovery.

Web app users may have a slightly higher tolerance for

underperforming products, but will still quickly lose interest

in a brand that does not offer a seamless experience. Yet few

software products are completely prone to failures.

One of the pillars of DevOps is to detect system problems before they

manifest or even stage certain failures to test how your system will

react. Whether you are planning to adopt Chaos Engineering practices

or not, it’s still worth to measure the next performance KPIs:

• Average uptime.

• Database response time.

• % of transaction time spent in database

• Database query times.

• Resources utilization.

• App response time.

Driver 4: Production Speed

Faster time-to-market is one of the key benefits of DevOps. But the

overall speed of development, deployment, and response time to

problems should not come at cost of compromised product quality.

To create the right balance, pay attention to the following indicators:

• Mean time to resolution

• Lead time for changes

• Frequency of code releases

• Time elapsed between deployments

• Wait time at each step

How to Assess Your DevOps Performance

4Users Have Low Tolerance For Buggy Apps – Only 16% Will Try A Failing App More

Than Twice: TechCrunch

23How to Assess Your DevOps Performance

Delivery and deployment can be significantly accelerated by

adopting continuous delivery and utilizing automated testing

tools and cloud computing services. IaaS and PaaS platforms

eliminate the need to provision and manage servers, networks,

or storage.

Driver 5: Product Quality

DevOps bridges the gap between fast development and great

software. By improving core business processes, eliminating

redundant and ineffective practices and reducing the time spent

on reactive actions (bug fixing) versus proactive efforts (building,

testing and shipping), the practice enables companies to create

high-quality products within shorter timeframes.

To understand how you are performing at this department and

whether your current initiatives pay off, take a close look at the

following metrics:

• Deployment success rate

• App error rates.

• Incident severity

• Outstanding bugs

• Outstanding support tickets

• Frequency of broken builds

• Ratio of manual and automated tests

Certain quality issues may not emerge up until the production

stage, so it’s important that you compare all of these metrics pre/

post deploy to get a bird’s-eye view.

Aligning your DevOps transition with the following drivers should

give you an overall idea of your current state of DevOps maturity

and pinpoint new areas for further optimization. By constantly

assessing your DevOps performance, you find new ways to

prioritize improvements and quantify the performance results

with each new automation or process upgrade.

24

Moving Forward With DevOps

Transitioning to DevOps is a major mind- and operational shift. The practice revamps how your company develops and delivers software and the change involves multiple business units and technical infrastructure. Rapid change is not always welcome. To avoid facing a backlash, break the transition process into smaller steps.

Your teams should experience small victories as the process takes place, to stay motivated and feel comfortable about the upcoming bigger changes. Invest in your development and IT operations staff as they are the employees who will feel the most tension – their jobs are on the line. They are also the key people who will drive further DevOps adoption for your entire organization.

Everyone should understand why the transition is taking place, how they should respond to it and what new success metrics they should adhere to.

Infopulse team will be delighted to assist you in your journey towards DevOps adoption. Our professional team of consultants can help you develop a new operational framework from the ground or help with transitioning an ongoing project. Make the first step towards faster time to market, increased teams’ efficiency and better product quality by scheduling a discovery session with our experienced professionals.

25

Infopulse, part of Nordic IT group EVRY A/S, is an international vendor of

services in the areas of Software R&D, Application Management, Cloud & IT

Operations, and Cybersecurity to SMEs and Fortune 100 companies across the

globe. We practice a full ‘value chain’ approach – from simple maintenance

to product development; from basic research to complex consulting. We’ll be

delighted to assist you with your transition to DevOps and conduct a deep

assessment of your current business setup; pin down the key success drivers

and suggest a roadmap to action. We “speak the language” of the Industry,

having advanced knowledge in technology architecture, IT security, project

management, delivery methodologies, and other functional domains.

About InfopulseContact us:

Follow us:

www.infopulse.com

Max Evdokymov

Head of Application Management

+380 (44) 585-25-00

m.evdokymov@infopulse.com