Release deployment and patch management are
practices that are tightly integrated.
As the services that are being delivered in the cloud become more
comprehensive and the demand for delivery speed increases,
release deployment and patch management are becoming seamless in output.
When we talk about release management, we're saying that the provider,
or the one who is consuming,
makes available new and change services and features for use,
a version of a service or configuration item that is being made for use.
When we speak of deployment management, this is moving new hardware,
software, documentation, processes, or services,
or other components, into a live environment.
And finally, when talking about patch management,
we're actually referring to updates to a system to fix
functionality features or some type of security.
With release management,
this is responsible for minor or major changes to existing services or
features of a system that can be based on complex capabilities.
The release plan will specify the exact combination of
change components and the timing for release.
The schedule's decided mutually between provider and consumer and has
a post‑implementation review for lessons learned.
In most cases,
most of the work effort of release management is done well before deployment.
In Agile DevOps environments,
the major activity or release management in
deployment management may be reversed.
There may be significant activity after deployment.
Some organizations are adept at applying Agile,
Lean, and DevOps, or ALDO,
techniques to have vertically‑integrated deployment teams.
The stages of release management may begin with a private group of users to
ensure that the requirements and functionality have been met.
A blue/green approach may be used where the organization has a mirror of the
production environment and logic that can switch users to the new environment
once confidence of functionality is reached.
Feature flags may allow a particular change to be deployed to a
production environment without being released,
allowing users to self select when they want it.
Deployment management is the practice of moving new and changed hardware,
software, documentation, processes,
or service components into a live environment.
While deployment management is closely aligned and associated
with release management and change control,
it is distinctly different in its practice.
This could be deployment of both infrastructure and software.
There are various approaches, like phase deployment,
where you do incrementally‑change components that are deployed for specific
parts of production environment; continuous delivery,
where you have frequent deployment with tight integration and testing
that conforms to amplified customer feedback; big band,
where you do updates that are deployed to all production
targets simultaneously; and pull deployment,
where you have updates that are held in repositories and can
be triggered at the discretion of the user.
When we're talking about patch management,
we're saying that we should have a patch policy that can describe the
rectification of an issue with functionality or a security.
The availability of the patch can be both inside of
a push or a pull environment.
An organization needs to consider the risk involved with both
applying or not applying vendor patches,
so vulnerability detection, evaluation by the vendor,
subscription mechanisms, severity assessments of the patch,
applicability of the patch,
all these things are part of the consideration of risk.
There should also be a determined customer notification
for applicable patches when required.
And obviously,
this is going to be fed back into the change management process just
like all the other managements that we have considered.
A child of the DevOps approach would be what's called
continuous integration and continuous delivery.
It is both a philosophical and practical approach to implementing
minute instantiations of code and checking those instantiations into
code repositories on a frequent basis.
So,
this would have to do with building packages and testing these packages in a
secure world so that the delivery of them could be as expected.
In many organizations,
there needs to be a unified platform and process for integrating the
various platforms and tools used within an organization.
The integration of these tools allows for this world,
where you have a minute changes happening on a constant basis so
that the customer is actually not disturbed by big,
gigantic changes,
but is actually improving their consumption of a system over time,
possibly without notice.
Mutable versus immutable environments means that we are moving away from
managing systems like we are inside of a data center.
When we talk about mutable,
that means that you're constantly updating systems and
making sure that those systems get patched like you would a
server inside of the data center.
Whereas inside of immutable environment,
VMs are not preserved when they are out of date.
The difference is that a mutable environment has changes
that occur over a longer period of time.
Whereas immutable environments say, you know what,
this is not a physical item,
so I'm actually going to destroy it and recreate a new,
golden‑level version, a version‑controlled image,
I'm going to instantiate that.
With mutable, we get to a pretty‑high level of automation,
but with immutable, we are highly dependent on the automated environment,
so this is a really important concept to understand.
Not running your cloud environment as you would a data center.
The data center is the mutable environment.
The cloud environment should be immutable.
Here are some systems that support you in running in an immutable environment.
A growing trend is to stop treating the cloud environment like a data center,
stop maintaining workloads like you would in a data center.
This extends the discussion of mutable verses immutable by actually
choosing Function as a Service or serverless architecture,
which means that you would also be bypassing VMs and going to
things like containers and microservices.
The microservice is a form of architecture that segregates
function of an application into discrete,
decentralized, and business objective‑driven processes.
Each can be independently built, deployed, and managed.
The implementation could be in things like databases and
message queues and key‑value stores, and all kinds of tooling.
Microservices don't share system state with peers and therefore
run efficiently without heavy interdependencies.
Containers are a small form factor and independent executable packages of
software that are installed and maintained upon a host operating system and
have everything needed to run an application,
which includes system tools, library, settings,
code.
The primary goal of using a microservice with
containers are continuous integration, continuous deployment.
When something actually gets out of state,
you can then just blow that thing off and instantiate a new copy of this code,
unlike which you would have to do on a server inside of a data center.
So, you're two leading container technologies, Docker and Kubernetes.
Docker is a set of coupled Software as a Service,
Platform as a Service products that use operating
system level of virtualization.
And then Kubernetes is an open‑source container orchestration
system for automating the application deployment,
the scaling, and the management.