Solving Media Identity Problem in DevOps Methodology

Today, many talk about DevOps as a methodology that helps break the “iron curtain” between the IT department, QA and programmers, and create some kind of common mechanism to help make products faster and better. The main task that confronts DevOps developer is to achieve maximum automation of deployment development. testing, production environments and transitions between them. Accordingly, one of the main problems in this case is to observe the complete identity of the development, testing and operating environments. Under the cat, I will give an example of a practical solution to this problem, which I used in several companies during the integration of the DevOps methodology.

Since this is a working example, I will immediately describe the limitations that are set when solving this task:

• A stable version of a popular rpm-based distribution with a large community where it can help solve typical OS-related problems. CentOS was chosen as it is currently the most popular rpm-based distribution.
• The possibility of versioning the environment. Programmers were engaged in the development of several forks of the product on CentOS 5 and CentOS 6
• Mandatory set of software for correct operation and deployment of the product (this is an example, in reality the list was much more):
  For CentOS 5:
  
  • python => 2.4
  • python IPY
  • python-simplejson
  • mysql-server> = 5.0
  
  For CentOS 6:
  
  • python => 2.6
  • python IPY
  • python-simplejson
  • mysql-server> = 5.1
  
  

At the time when I first asked myself this problem, there were no ready-made solutions, and even now this is a rather specific moment and I haven’t yet found common solutions. As a rule, these are some internal scripts that are honed for specific products.

To unify this solution, I developed a build-tools utility at https://github.com/scopenco/build-tools , which allows you to create RHEL , CentOS , Fedora , Scientific yum repositories with a meta package (project package) based on XML specifications (aka roles) . Roles describe a set of required packages and repositories, from where these packages along with dependencies are downloaded to the local yum repository (aka build). This repository is used as a package base for the product.

So the build-tools installation is very simple and is described in the README .
Let's pass to project specifications.
Example specification for CentOS 5:
')

<?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.1" > <!-- role with minimal set of packages --> <role path="roles/centos-5-minimal.xml" /> <!-- python packages --> <package name="python" version="2.4.3" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.0.95" /> <!-- yum repos --> <role path="repos/centos-5-base.xml" /> <role path="repos/centos-5-updates.xml" /> <role path="repos/centos-5-epel.xml" /> </project> 

Example specification for CentOS 6:

 <?xml version="1.0" encoding="UTF-8"?> <project name="myproject" summary="My First Project" repository="http://repo.domain.com/pub/repo/" version="0.2" > <!-- role with minimal set of packages --> <role path="roles/centos-6-minimal.xml" /> <!-- python packages --> <package name="python" version="2.6.6" /> <package name="python-IPy" /> <package name="python-simplejson" /> <!-- mysql packages --> <package name="mysql-server" version="5.1.71" /> <!-- yum repos --> <role path="repos/centos-6-base.xml" /> <role path="repos/centos-6-updates.xml" /> <role path="repos/centos-6-epel.xml" /> </project> 

The difference is essentially only in the connected yum repositories and roles with a minimum set of packages.
To build the yum repository and meta packages, you can use ready-made scripts, or you can write your own with deeper automation and integration into the development process.

 cd src cp ../repository . ./build-el5.sh ./build-el6.sh 

Repositories are compiled on CentOS 5. This is due to the fact that yum is not backward compatible and the repositories collected via the Centus 6 yum API will not be installed on CentOS 5 machines, while the repositories collected on CentOS 5 are installed on CentOS 6, Fedora 13 and above, Scientific 5 and above.

After launching the assembly, the output is a 2-repository, from which you can upload physical and virtual servers by kickstart . Thus, a set of software is fixed, which can be stored in the corporate repository and used to deploy the product.

You can create new roles with public yum repositories and packages for customizing environments.
Consider several popular options:

• Suppose for the testing environment you need to add some additional rpm packages, which should not be in production. In this case, a separate role is created with a list of these packages and a separate project for the testing environment, where this role is added along with the roles for other environments. Building builds for all environments needs to be done on the same day so that the versions of packages in builds for development and production do not differ from testing but only their number.
  
• Suppose there is a regulated list of software that must be present on all servers of the project. In this case, a separate role is created with this list, which is added to all project specifications. This way it is guaranteed that the software will be installed on all servers.
  

A detailed description of the attributes can be found in the wiki build-tools .

If we talk about an update that happens sooner or later, then in this case it will suffice to encoding the version in the project specification and rebuild the build. It will turn out a new build with a new version that can be deployed or updated in development, testing and operating environments.

Results:
Thus, using build-tools I managed:

1. solve the identity problem of development, testing, production environments
2. provide developers with ample opportunities for versioning the environment and software compatibility throughout the project