Release Management and Deployment Essentials

[article]
Summary:
Business requirements often dictate how changes in release management are addressed. But by following some essential practices and core beliefs, database deployment does not have to result in the headaches once caused.

As a result of software becoming more embedded in business, firms are discovering that the pace of change is now limited by how quickly they can react to shifting business requirements and deploy new releases of their supporting applications. Additionally, as technology evolves, software application architecture is becoming increasingly complex, shifting to distributed and multi-tier models. This architecture poses multiple challenges when deploying new releases.

In order to ensure a complete, error free release process, changes to all application tiers must be coordinated with every release of a new version. A new version should include updates to the binary code, configuration files and changes in the database objects. In order to have a complete and successful release, one should manage the release and the deployment. Much like assembling a car, all pieces must fit together, and assembled at the right time.

As the architecture becomes more complex, the team structures change to support this complex architecture, so much so that it is not uncommon to see several development teams supporting a single application. These teams may be organized by technologies, different geographical locations, or other criteria.

Software release methodologies became part of ITIL, PMBOK, CMMI and other best practices in response to the increased pace and complexity during the last decade,.

In order to understand the software release process, we should remember that application tiers can be divided into three groups:

1.     Binary code
2.     Configuration files
3.     Database artifacts

Binary codes contain all the binary files created during the build operation, converting Native code, such as C++, Java, C# into binary executables.

Configuration files include configuration files of the application, usually in XML format and infrastructure, such as web servers, transactions servers, and network definition.

Database artifacts contain the portion of the application that resides in databases. This can also be broken into three groups:

    • Business logic - code in database specific language, the database objects can be packages, procedures function, triggers etc
    • Schema structure - the structure of the entities in the database, such as tables, views, indexes, synonyms
    • Lookup data – parameters and information required for the business logic

Deployment End-to-End
Multiple products address the deployment of binary code and configuration files, ranging from those that automate the build processes through products that automate the packaging, to others that automate the deployment and delivery of binary code and configuration files. You can find commercial products as well as open source solutions across these products. However, a complete release and deploy solution should cover all application's tiers, without focusing exclusively on the binary code and configuration files.

Database objects present unique challenges during deployment, since they cannot simply be replaced, as is common for binary code elements and configuration files. Database changes must preserve the data stored, or the business will lose its information.

To better understand these unique challenges, let's take a quick look at what is required out of good database deployment solutions:

    • Comparing and syncing
    • Deployment based on business requirements
    • Merging of conflicts

Comparing and Syncing
Comparing and syncing make up the foundation of a deployment solution. This consists of comparing database code, structure, and lookup data between environments (development, testing, UAT and production), in addition to automatically generating a deployment script that will alter the target environment (production sites) structure, as well as lookup data, to be identical to the source environment (development or integration environments).

This process enables us to change the structure of the target environment to match that of the source environment, without losing the most important asset, which is the most up to date content of the database (the only

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!