0% found this document useful (0 votes)
24 views9 pages

08 Versioning

This document discusses configuration and script management which are important for continuous DevOps deployment. It covers having a good configuration management strategy where all environments are set up the same way using version control. It also discusses the importance of being able to recreate or rollback production systems if needed. The document provides recommendations for version controlling all project artifacts, using scripts to define infrastructure, data, and configurations, and best practices for script management in deployment pipelines.

Uploaded by

pablo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views9 pages

08 Versioning

This document discusses configuration and script management which are important for continuous DevOps deployment. It covers having a good configuration management strategy where all environments are set up the same way using version control. It also discusses the importance of being able to recreate or rollback production systems if needed. The document provides recommendations for version controlling all project artifacts, using scripts to define infrastructure, data, and configurations, and best practices for script management in deployment pipelines.

Uploaded by

pablo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

DevOps  

Deployment  Module  8    

We're glad to see you back in this video education series


on DevOps deployment, brought to you by IBM Agile Academy.
This is Module 8, configuration and script management.
So, why is this topic important? Configuration and script
management both support continuous DevOps deployment.

By following the practices described in this module, you


will learn what constitutes an effective configuration
management strategy. This topic will talk about the
importance of setting up all your environments the same way
using the same scripts.

We will also talk about the importance of being able to


recreate your production system and even roll back to a
previous version if a problem occurs during or after a
deployment.

Continuous integration and automated push button


deployments depend on having everything related to your
project in a version control repository. We will cover
these points in this module.

What is configuration management? How do you determine if


you have a good configuration management strategy? What

are the recommended techniques and practices for version


control and script management? And where can you find
resources to learn more?

-1-
DevOps  Deployment  Module  8    

According to Jez Humble, configuration management is


synonymous with version control, which is used to keep
track of different versions of your project or application
as well as its components and artifacts.

The definition of configuration management is the process


of storing, retrieving, identifying and modifying all the
artifacts related to your project and the relationships
between them.

Having a configuration management strategy is key for any


project because it is a plan on how you will manage you'll
the changes within your project.

You know you have a good configuration management strategy


if you can answer yes to the following questions. Can you
completely recreate your production system, excluding
production data, from scratch from the version controlled
assets that you store?

Could you regress to an earlier, known good state of your


application? Can you be sure that each deployed
environment in production, in staging and in test is set up

in precisely the same way?

Shown here is an example of what not to do for version

-2-
DevOps  Deployment  Module  8    

control. Storing your files on USB drives in a drawer is


not version control. Also, a lot of people think that
version control is only for source code, but it's not.

It's for every single artifact that is related to your


project. So, you need to include source code, tests,
database scripts, database object, build and deployment
scripts, documentation, libraries and configuration files
and so forth.

This will enable you to recover an exact snapshot of the


state of your entire system. Gene Kim and Jez Humble, in
collaboration with Puppet Labs, put together a state of
DevOps research study last year, and one of the most
interesting findings was that version control was one of
the highest predictors of performance.

Organizations that used version control were typically more


organized and had more frequent deployments, as well as
faster service restoration times when something went wrong.

The key to versioning everything is to ensure that all


source artifacts are in scripted form. So, infrastructure,
data, configuration and application code are all in

scripted form.

As many of you already know, application code can be easily

-3-
DevOps  Deployment  Module  8    

versioned. But how about infrastructure or data or


configuration? Let's talk about infrastructure first.

You can define infrastructure as code. What this means is


that you would define text-based scripts that can be
executed to create your environments. The script can be
run to download, install and run your server.

By combining different scripts, you can describe your


entire environment in scripts. Configuration is defined as
information that varies across environments. So, examples
are directory and file locations, host names, IP addresses
and server ports.

Scripts can be built using configuration information to


create environments, run builds and deployments and run
tests. So, what about data? You can use DDL, data
definition language scripts, to define and create the
database and table structure.

You can define data in data manipulation language or DML


scripts, including insert, update and delete statements.

There are many version control repository tools out there.

Some of the more popular ones are Git, Subversion,


Perforce, Bazaar and rational team concert with source
control management, part of a collaborative lifecycle

-4-
DevOps  Deployment  Module  8    

management suite.

We should keep everything in version control. As mentioned


before, version control is not just for source code. Every
artifact that is related to the creation of your software
or system should be under version control.

Okay. So we did say keep everything in version control,


right? Well, there is one exception. We would not
recommend keeping the output of your application's compile
in version control.

One reason is because it's really big and takes up a lot of


space so you could even have so many versions of it that
you're just wasting space. Another reason is that teams
should be able to recreate the compile output from the
source any time they re-run or run their build scripts.

Check in regularly to trunk. The benefits of version


control are enhanced when your team members and developers
especially commit on a regular basis to trunk.

Having the team commit frequently means that your changes


are available for other people on the team to see and to

interact with. Plus, you get a clear indication that all


of the changes being made have not broken the application
because merges are always small and manageable.

-5-
DevOps  Deployment  Module  8    

Use meaningful commitment messages. Every version control


system has the facility to add a description to the commit
process. But many team members forget to add a comment.
It's similar to adding comments in your code.

When many people write code and don't make a comment, it


can become confusing later and add to technical debt. If
you don't add a comment, then others will not know what was
added and what was committed to in the latest build.

Another important reason to write descriptive commit


messages is so that when the build breaks, team members
will know who committed the last build and what the new
edition was that they created.

Script management. Scripts are used during the build and


deployment processes. Here are some recommended practices
associated with script management. Create a script for
each stage in your deployment pipeline. When you first
start your project, it might make sense to have one single
script which contains every operation that will be
performed in your deployment.

In this case, you might have dummy targets or stubs for


those steps that are not yet automated. Once your script
starts to get populated, you can divide it up into separate

-6-
DevOps  Deployment  Module  8    

scripts for each stage within your pipeline.

Use minimal viable technology to deploy your application.


Automated deployments are key in a DevOps culture. If your
deployment process is extremely simple, you might be able
to use a script to automate your entire deployment.

However, in most cases, you should be looking for an


automated deployment tool. Even if you use an automated
deployment tool, it is likely you will still have to build
scripts to complete your deploys, since most tools will not
be able to deploy all of your artifacts.

Within IBM, the tool that we currently recommend is


UrbanCode Deploy. Use the same scripts to deploy to every
environment. This is an essential point because you need
to be using the same process to deploy to every
environment.

That means using the exact same scripts to deploy to each


environment and use your deployment script to retrieve the
correct configuration information based on the environment
to which you are deploying.

Use package tools. As part of your application's


deployment process, your team will typically need to deploy
a bunch of files that need to be distributed across the

-7-
DevOps  Deployment  Module  8    

file system. This can be very inefficient and makes


upgrades and rollbacks painful and difficult.

We recommend the use of packaging tools to bundle all of


the files together into one package and then it's easier to
deploy that package. Ensure the deployment process is item
potent. Your deployment process should always result in
the same target environment, regardless of the state of the
environment when starting a deployment.

The simplest way to achieve this is to start with a known


good baseline environment provisioned either automatically
or through virtualization. This environment should include
all the appropriate middleware and anything else your
application requires to work.

You should also perform testing to validate the process so


that you can stop the deployment if anything is going
wrong. Evolve your deployment system incrementally. Don't
try to build your deployment process in one day. Start
maybe with a script to deploy the application code and
automate the deployment of the application into a testing
environment.

Then move on to refining these scripts so that they can be


used in the acceptance test environment. Then, once again,
use the same process and tools to deploy the application

-8-
DevOps  Deployment  Module  8    

into other environments, like staging and production.

Like configuration management, there are many tools that


support script management. Some of the more popular tools
are Chef, Puppet, Docker, Ansible, Salt and even some IBM
Rational products. Here are some references where you can
learn more about configuration management and script
management.
[END OF SEGMENT]

-9-

You might also like