Establishing Integration Competency Center, part 3

Part 3: Release and deployment

High pace and quantum of changes – that is a one of the biggest problems of ICCs to handle. As integration platform grows constantly by new integration solutions and changes to existing ones, it is mandatory to design release and deployment processes with special care. We need cyclic process for deployment – if we deploy every change and new solutions as individual, we will deploy them constantly without having proper time for testing and acceptance. This is a fast lane to maintenance chaos. Cyclic is to gather changes and new solution to releases and install them in predefined schedule. Common setup is to have bi-weekly, monthly or bi-monthly releases.

Put every release through quality control. Lets imagine that there are only two independent solutions in our coming release and both of them are separately well-tested. If they are totally separate solutions they won’t have any impact on each other, right? Integrator, who makes this kind of assumptions ought to be shot at leg. Why? Because when dealing with complex integration platform there is always possibility that there is a surprise reaction such as how separate integration solutions lock or stress technical resources of the platform in unexpected way. Triggers to these anomalies are usually something that is out of our hands and exist in the platform by design – no way we could estimate them to happen without proper testing.

So it is major concern of ICC to ensure testing steps in release and deployment processes are not only covering all the new features but they must also make sure that separate deliverables do not set off any unexpected situations when put to run together with each other and existing integration processes.

One common source of glitches is bindings and parameters. They have a nasty tendency to sneak from development to test environment and from test environments to production environment during manual deployments. Try to aim for automated scripts that deploy each environment and change parameters automatically. Once you have set the environment specific bindings and parameters right, you don’t have to repeat and make mistakes on forthcoming deployments.

To summarize, make sure your release and deployment covers:

  • Cyclic schedule
  • Regression testing (preferably automated)
  • End-to-end and Acceptance testing (if not part of other processes and yes – aim for automation here too)
  • Automated deployment from environment to other

2 thoughts on “Establishing Integration Competency Center, part 3

  1. Pingback: Establishing Integration Competency Center, part 4 | Integration War Stories

  2. Pingback: Establishing Integration Competency Center, part 1 | Integration War Stories

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