- [Instructor] Change management aims to minimize
the business disruption of change,
and ensure we can answer the question what changed.
The simplest and most effective thing
you can do at the intersection
of ITIL driven change management and DevOps,
is to implement visible ops-style change control.
Also, you should expect with DevOps
that agility and velocity
will tend to trump risks and stability in
go/no-go decision about changes.
The DevOps postured towards change
is to enable and support change,
versus to enforce and control processes,
and to accept versus prevent failure,
with the idea that if you're not failing enough,
you're not trying enough.
With DevOps, change management becomes more about
monitoring, communicating and reacting to continuous change,
resulting from release pipelines,
rather than focusing on change control and delay,
as changes are smaller in scope and impact,
but much greater in number.
Another shift is toward mitigation and risk controls
around changes, for example no standing rights
in target environment, automated deployments,
automated mandatory testing and mandatory approvals.
These are being encoded into the change process.
With release and deployment management,
the aim is to ensure releases into production
are successful, enable effective use
and deliver customer value by defining
and agreeing on release and deployment plans
with customers and stakeholders.
Continuous delivery, infrastructure automation,
the cloud and blue-green deployment
are the DevOps aspects that have the biggest impact
on ITIL-Driven release and deployment processes.
Characteristics of release and deployment management
in a DevOps mode include
de-coupling of promotion or release from a code deployment,
a shift from releases tracked and ticketing systems,
to releases visible and available in code,
automated promotion from dev to test to prod,
automated and integrated testing that occurs
prior to and after promotion, smaller release packages
continuously released on a regular schedule,
automation of some or all engineering systems,
including backlog, source control, peer review,
testing, stage release, for example,
staging environments, AB testing, and feedback mechanisms.
Tight integration between tools and processes
creating a pipeline to release into production.
Production environments in most cases deploy new,
not upgraded, not modified, not changed.
And finally, the product owner approving the release
in deployment to production.
Knowledge management aims to ensure the right information
on service usage, consumption, delivery constraints
and obstacles to full realization of benefits,
is delivered to the appropriate place or competent person
at the right time to enable informed decisions.
One key impact of ITIL-driven knowledge management
with DevOps, is that the process focus shifts
from curating centralized aggregated knowledge
to just-in-time shared knowledge
through social collaboration, less let's-have-knowledge
articles in the ticketing system
and more let's-have-chat-offs.
This shift is driven by the rapid pace of change
in knowledge with the cloud and DevOps.
In a Dev-Ops mode, knowledge management
is role and context aware,
integrative of multiple information sources,
including external public content, internal content,
tool and component-specific content, like known defects,
and community-based resources, you know,
discussion forums and social media and what have you.
It's also available across multiple devices for consumption.
And it's aware that knowledge is changing fast
and of the other factions just mentioned here,
and takes that into consideration in its practices.
One thing to watch out for here is
without a shift in posture,
ITIL-Driven knowledge management can be overrun
with service management types wanting documentation
and DevOps types not wanting to write anything down.
This is a big area for potential head-butting,
so tread carefully here.
Transition planning and support aims to ensure
that the requirements of service strategy
encoded in service design, are effectively realized
in service operation by coordinating and planning
the resources required to successfully deliver
new and changed services into the production environment.
Transition planning and support helps herd the cats
across all service transition activities.
Within terms of fighting flight control
across transition activities, for example making sure
transition activities have the resources they need,
don't step on each other, et cetera, et cetera,
but also coordinating activities with things like
policies, templates and standards.
A key idea here is to level resources
and minimize irrational variation.
With DevOps the manual overhead involved in transition
planning and support is greatly reduced through automation.
Automation to build pipelines for continuous delivery,
automation to eliminate or reduce variation
and dependencies, automation for compliance
with process policies, and through practices
supported by technologies such as blue-green deployment.
The most important thing to note here
is that with DevOps, there is still need for coordination
across transition to production activities,
but how this gets done is much more automated.
Change evaluation aims to formally assess new
or changed IT services to ensure risks have been managed
and to help determine whether to authorize the change,
to ensure there is a good business case
for any major changes, changes involving major disbursements
of funds, allocations of resources
or major risk or opportunity.
So having a look at that before such changes move forward.
With DevOps, there is still a need for a business case
to be made before such changes.
The difference with DevOps is in the nature
of the financial discussion.
For example, in sprint planning and retrospectives.
Service validation and testing aims to ensure
that new or changed services deliver customer
and business value, by ensuring that the service offering
is fit for purpose and fit for use.
The objective of service validation and testing
is to ensure that deployed releases
and the resulting services meet customer expectations.
This IDIL process verifies that IT operations
is able to support the new service.
As with other things DevOps, one big change here
is that the level of automation and validation
in testing is much higher.
Also, with smaller, plus faster equals better practices,
the typical unit being validated and tested
is smaller, and it's happening much more frequently.
One of the biggest adjustments here between ITIL-Driven
service validation and testing practices and DevOps,
is adjusting to working with agile scrum team practices
and work pace.
One thing you can do here is to make sure
that those involved with service validation and testing
are familiar with agile and scrum practices.
Service asset and configuration management aims
to ensure a logical model of the IT infrastructure
that correlates IT services, assets and IT components
needed is defined, controlled, maintained
and kept accurate as a source of information
for fact-based management of IT services
and to comply with corporate governance requirements.
With DevOps, the center of gravity
of configuration management shifts left, towards Dev,
to focus on the scripts and templates and pipelines
used to build systems, applications, services,
in a way for making sure you know the configuration
you're managing.
This is for one simple reason.
When you move from pets to cattle,
you already know what things look like.
For example, if it's a SQL box, it's either small,
medium or large, but other than that,
they all look the same, cattle.
Immutable deployments further put in the element coffin
of shift right approaches and configuration management.
Another key shift here is that in DevOps,
the set of relationships between people, technology,
data, infrastructure, costs and geographies
to create an as-is environment,
is assumed to be relatively dynamic.
Whereas, relatively speaking, the L-driven assumption
was one of a more static environment.
So in DevOps, look for an emphasis for configuration
management to offer a high degree of automation
for discovery, correlation and visualization
of realtime dynamic relationships.
Some of the other shifts you'll see
with configuration management in a DevOps mode,
include a shift from a lagging, discovered and audited
posture to one that is more leading, declarative
and monitored.
A shift from annual, semi-automated data entry
with manual intervention required for accuracy,
towards continuous automated and declarative,
with CIs itself identifying attribute
and relationship information.