Release Engineering and Systems Implementation

Posted: December 7, 2016 in Information Technology

Continuing my series on Release Management, I thought I would write an article with regard to larger Systems Implementation and Planning. Many times, especially with DevOps we speak about smaller systems, web applications, or even mobility apps. 512px-ComputernetworkHowever, there are still quite a few large, complex systems that undertake a release activity that may require much more activity and planning.  In Release Management, we call this out in the Release Planning phase with respect to the change scope making up a Release.  Changes are scoped to a Release.  The change scope specifically then determines the impact of how complex the release will be. The Release determines the environment needs as well as what the environments or systems will need a regression test.  That activity does not change even with the smaller releases.  The difference is larger IT releases in the amount of systems needed.   However, for larger IT systems there are a few things in play here.

There are a few things to consider when the Release starts to grow complex with other IT Systems.  You have Systems Engineering activities to implement the effected systems for the release, and you have Software Engineering which may focus on the specific release build or development effort, either in 1 system or multiple.   It’s the Systems Engineering that is the challenge to determine what systems will need to be set up, staged, and prepared with data.  You also have the integrations whether they be db link, Informatica or ETL technologies, API, or Web Services technologies that connect the systems together.  Part of being a good Release Manager is working with the Solutions Architecture team, Developers, Testers, and Business Analysts for the Business Application to determine these impacts and needs. Some systems are used “as is” where the release will not have a change to a system needed. However, the system is required for proper Test Environment set up and will have requirements needs specific to the test preparations.  The Release Team will also work with the Test teams to determine the Test Environment requirements, what integrations, what ETL Jobs, what data.  Once all these requirements are defined, the work starts to engineer the Test Environment so that you have a proper test bed for the release build.   Years ago we called this important activity Test Environment Engineering because to prepare the environments to test the systems changes that were impacted, the release build took some effort to prepare the environment for these larger complex systems.  Today, the term has evolved into Environment Management.

Environment Management is simply tracking your non-production and production environment states, reserving them for the test effort so you don’t have a free-for-all, the environment preparations, and also controlling them so you have confidence in the environment state while undergoing test cycles.   Key activities for Environment management has to include configuration management, the version of the components as well as the date and type of test data.  Tools such as Test Data Management allow you to stage specific data sets that are re-usable for each test cycle. Having a stable test data set that allows the test teams to repeat test cycles and also confirm and close out defects.  It is one approach, however, you will find that systems that insert a primary key for a row of data makes it difficult to re-use the data without having to reset all the effected systems back to their original set.  In large complex environments, even with a subset, it can be time consuming to prepare for these cycles.   Test Engineering resources have to know the data model, the data movement for integrations, and how these integrations work. They usually work with the architecture maps.   You will also find when setting up an complex integrated test environment  such as this picture depicted below, that you will be working with various teams to determine what data has to be near sync due to primary key concerns, and what services are needed to properly test the Release Build.

complex_systems_integrated

Widget IT System showing Integrated Systems. Yes, some can be this complex!

There are also other valuable reasons why the Release Team needs to participate this activity.  It is the value and knowledge of the steps and activities, timing, the sequence of steps that aids in a really good Deployment Plan.  And this key knowledge that the Release Team undertakes is one reason why ITIL has a specific call out to the activity.  This is your team that has the knowledge on these systems, how a proposed change impact will effect the system, and how they may think about implementing the change into the system.  It goes beyond the visibility that the Development Team or Developer may have specific to the Release Build, and it is a different set of criteria and thinking since they are focused only on implementation of the change or the Release.  It’s a team where you want some stability without high turn-over of resources. It’s a team that learns by repetition and experience.

Do these concepts also help the smaller, less complex Releases?  You bet!   The same concepts apply.  Change Scope drives the complexity of the Release for what Environments you need, what is impacted, what needs regression testing. The Release planning involves this Environment Management activity.   Environment Changes and the tracking of the Release Build then drive the Deployment Planning efforts.  Deployment Planning looks at how to implement the Release, the roll-out, the back-out contingency, and the team stakeholders to help the deployment be successful.


William is a certified Practitioner in IT Service Management for Release and Control, with experience in Global Change, Configuration and Release Management.  He is also an experienced Project Lead in delivery, IT Automation, systems implementation, build, deployment and release practices.

This article is in a series of articles around IT Change, Configuration and Release Management using ITIL’s Foundation Framework.

Copyright. William Mantz 2016. All Rights Reserved.
Images used with permission from GNU, please see Image Description or Alt Tags for attribution.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s