Start here: DevOps

Site: Digital Learning Portal

Course: IBM Cloud Private Continuing Education Series: Continuous Integration/Continuous Deployment Pipelines
Book: Start here: DevOps
Printed by: Rajendra Kumar Bhandari
Date: Wednesday, November 6, 2019, 10:43 PM
Table of contents
1. Short overview of DevOps

2. How does DevOps work?

3. DevOps capabilities: Reference architecture

4. DevOps and the cloud

1. Short overview of DevOps
DevOps is short for development and operations. DevOps is an approach based on lean and agile principles in which business owners and the
development, operations, and quality assurance departments collaborate to deliver software in a continuous manner. This approach enables
the business to more quickly seize market opportunities and reduce the time to include customer feedback. Indeed, enterprise applications
are so diverse and composed of multiple technologies, databases, end-user devices, and so on, that a DevOps approach can be successful
when dealing with these complexities.

DevOps is a business-driven software delivery approach — an approach that takes a new or enhanced business capability from an idea all the
way to production. This provides business value to customers in an efficient manner and captures feedback as customers engage with the
capability. You need participation from stakeholders beyond just the development and operations teams. A true DevOps approach includes
lines of business, practitioners, executives, partners, suppliers, and so on.

One of the tenets of DevOps is to develop and test on a production-like environment.

Adding to the bottleneck of environment availability is the challenge of the available
environment not matching the production environment. This mismatch may be just as
simple as differences in configuration of the environment — at the operating system
(OS) or middleware level — or as drastic as a completely different OS or middleware
type on the development environments from what is used in production.
2. How does DevOps work?
DevOps adoption has produced several principles that have evolved over time and are still evolving. Most solution providers have developed
their own variants. All these principles take a holistic approach to DevOps, and organizations of all sizes can adopt them.

Develop and test against production-like systems

This principle stems from the DevOps concept shift left, in which operations concerns move earlier in the software delivery life cycle, toward
development. The goal is to allow development and quality assurance (QA) teams to develop and test against systems that behave like the
production system, so that they can see how the application behaves and performs well before it is ready for deployment.

The first exposure of the application to a production-like system should be as early in the life cycle as possible to address two major potential
challenges. First, it allows the application to be tested in an environment that is close to the actual production environment. Second, it allows
for the application delivery processes themselves to be tested and validated upfront. From an operations perspective, this principle has
tremendous value. It enables the operations team to see early in the cycle how their environment will behave when it supports the application,
thereby allowing them to create a fine-tuned, application-aware environment.

Deploy with repeatable, reliable processes

As the name suggests, this principle allows development and operations to support an agile (or at least iterative) software development
process all the way through to production. Automation is essential to create processes that are iterative, frequent, repeatable, and reliable, so
the organization must create a delivery pipeline that allows for continuous, automated deployment and testing. Frequent deployments also
allow teams to test the deployment processes themselves, thereby lowering the risk of deployment failures at release time.

Monitor and validate operational quality

Organizations typically are good at monitoring applications and systems in production because they have tools that capture production
systems’ metrics in real time. This principle moves monitoring earlier in the life cycle by requiring that automated testing be done early and
often in the life cycle to monitor functional and nonfunctional characteristics of the application. Whenever an application is deployed and
tested, quality metrics should be captured and analyzed. Frequent monitoring provides early warning about operational and quality issues that
may occur in production. These metrics should be captured in a format that all business stakeholders can understand and use.

Amplify feedback loops

A goal of DevOps is to enable organizations to react and make changes more rapidly. In software delivery, this goal requires an organization to
get quick feedback and then learn rapidly from every action it takes. This principle calls for organizations to create communication channels
that allow all stakeholders to access and act on feedback.

• Development may act by adjusting its project plans or priorities.

• Production may act by enhancing the production environments.
• Business may act by modifying its release plans.
3. DevOps capabilities: Reference architecture
The DevOps reference architecture shown here proposes three sets of adoption paths with different practices:    

• Deploy
• Develop/Test
• Operate       

Develop/Test
Software delivery efforts in an enterprise involve large numbers of cross-functional teams, including lines-of-business owners, business
analysts, enterprise and software architects, developers, QA practitioners, operations personnel, security specialists, suppliers, and partners.
Practitioners from these teams work on multiple platforms and may be spread across multiple locations.

Collaborative development enables these practitioners to work together by providing a common set of practices and a common platform they
can use to create and deliver software. One core capability included within collaborative development is continuous integration, a practice in
which software developers continuously or frequently integrate their work with that of other members of the development team.

Continuous integration was made popular by the agile movement. The idea is for developers to regularly integrate their work with that of the
rest of the developers on their team and then test the integrated work. In the case of complex systems made up of multiple systems or
services, developers also regularly integrate their work with other systems and services. Regular integration of results leads to early discovery
and exposure of integration risks. In complex systems, it also exposes known and unknown risks — both technical and schedule-related.

Deploy
The Deploy adoption path is where most of the root capabilities of DevOps originated. Continuous release and deployment take the concept
of continuous integration to the next step. The practice that enables release and deploy also enables the creation of a delivery pipeline. This
pipeline facilitates continuous deployment of software to QA and then to production in an efficient, automated manner. The goal of continuous
release and deployment is to release new features to customers and users as soon as possible.  Most of the tooling and processes that make
up the core of DevOps technology exist to facilitate continuous integration, continuous release, and continuous deployment.

Operate                   
The Operate adoption path includes two practices that allow businesses to monitor how released applications are performing in production
and to receive feedback from customers. This data allows businesses to react in an agile manner and change their business plans as necessary.

Continuous monitoring provides data and metrics to operations, QA, development, lines-of-business personnel, and other stakeholders about
applications at different stages of the delivery cycle. These metrics are not limited to production. Such metrics allow stakeholders to react by
enhancing or changing the features being delivered and/or the business plans required to deliver them.

Continuous customer feedback and optimization. The two most important types of information that a software delivery team can get are
data about how customers use the application and feedback that those customers provide upon using the application. New technologies allow
businesses to capture customer behavior and customer pain points right as they use the application. This feedback allows different
stakeholders to take appropriate actions to improve the applications and enhance customer experience. Lines of business may adjust their
business plans, development may adjust the capabilities it delivers, and operations may enhance the environment in which the application is
deployed. This continuous feedback loop is an essential component of DevOps, allowing businesses to be more agile and responsive to
customer needs.
4. DevOps and the cloud
The lack of availability of environments results in potentially significant wait times for practitioners. The mismatch between development and
production environments can introduce significant quality issues. Developers cannot verify how the application being developed will behave in
the production environment, or if it can even be deployed to production through the processes used to deploy to test environments.

Cloud addresses these

problems in the following
ways:

• The speed of environment

provisioning on cloud
platforms can provide
practitioner self-service to
the practitioners with on-
demand environment
availability and access.

• The ability to dynamically

provision and de-provision
these environments as
needed allows for better
environment management
and cost reduction by reducing the need for permanent, static test environments.

• The ability to leverage pattern technologies that allow organizations to define and version environments as software allows for the
availability of provisioning environments that match the practitioners’ needs — and more importantly are production-like environments.

Deploying a cloud application consists of deploying the application and configuring the cloud environment on which it runs. These two tasks
can be performed separately, but when they are combined, this is known as a full-stack deployment. 

The first approach is to separate the cloud environment provisioning from application deployment. In this scenario, there is no single point of
orchestration of cloud environments and the applications that are deployed on them. The application deployment automation tool simply sees
cloud environments as static environments. This scenario does not maximize the benefits of deploying to cloud.

The second approach is to leverage the deployment automation tool as the single orchestration tool for cloud environment provisioning and
application deployment to the environments provisioned. You can achieve this by creating blueprints that capture the cloud environment
definition and topology.  Blueprints then map the application components and configurations to the nodes defined in the cloud environment.