Release and Deployment Approaches

Release and Deployment Approaches:

Release management is responsible for planning, scheduling and controlling the movement of new or changed services in the form of a release packages, to both the testing and the live production environments.

Any new system will bring about change in the structure of the client’s organization. However, users don't always welcome change. A degree of resistance to organizational changes is normal. The project manager's biggest challenge is guiding the client through the necessary changes. The release and deployment approach are:

Big Bang versus Phased approach release:

The big bang approach refers to a complete changeover to the new system at a specific point in time. This approach has a significant impact on the client's business processes. Smaller companies usually favour this approach. Most big bang projects have fast and intense implementation periods, with more downtime during the implementation.

The big bang approach is easier to implement but requires more preparation, planning and human resources than the phased approach. The big bang approach is generally more expensive than the phased approach. Companies must have a clear mandate from top management, an experienced project manager, a proven implementation methodology and thorough user training for a successful big bang implementation.

Considering all of these factors, the big bang approach is a little more risky.

On the flip side of the coin we have the phased approach. This approach requires a long-term commitment to the implementation. This can either be by functional business area or location. The phased approach relies a great deal on the cooperation and communication between the client and the project manager.

Initially the phased approach will require more maintenance for testing and fine-tuning during the implementation of the system. Constant changes and corrections could become de-motivating to the development team and the project manager needs stricter control during this process. It is the project manager's greatest challenge to keep the development team focused for the duration of the project. Completing a phased implementation successfully requires a great deal of planning.

The phased approach is more cost effective, as it requires fewer resources.

Types of Releases:

There are three main types of releases. The first is a major software/hardware release. This release, whether it is for fixes to major glitches in a previous release or an entirely new product. This type of release takes precedence over all other releases because it fixes major problems. On top of that, it removes all fixes that were done by minor problems.

The next type of a release is any sort of software/hardware release that is minor. This release is for fixes on minor problems. A minor release removes all fixes that were done by an emergency release.

The final type of release is an emergency release. If something suddenly appears that is wrong in software or hardware, this release ensures that it is fixed in a timely fashion. They are very small, pinpointed releases

Push versus Pull deployment:

In a Pull deployment model, the individual servers contact a master server, download their configuration and software, and configure themselves. In a Push model, a master server pushes the configuration and software to the individual servers and runs commands remotely.

Advantage of pull model:

1. When a new server comes up it can get instructions from the master and start doing things. You can’t push instructions to a server that isn’t there, and the server itself is most aware of when it is ready to do stuff.

2. If a lot of servers come up, they can all do the setup work on their own, they only have to ask the master what to do.

Advantage of push model:

1. Easy to bootstrap. A bare server can be setup with push, no customization needed. Any customization is another kind of configuration, and configuration should be automated, and… well, this is why it’s a bootstrap problem.

2. Errors are synchronous: if your setup code doesn’t work, your push system will get the error back, you don’t need some fancy monitor and you don’t need to check any logs. Weird behavior is also synchronous; can’t tell why servers are doing something? Run the commands and watch the output.

3. Development is sensible: if you have a change to your setup scripts, you can try it out from your machine. You don’t need to do anything exceptional, your machine doesn’t have to accept connections from the slave, you don’t need special instructions to keep the slave from setting itself up as a production machine, there’s no daemon that might need modifications… none of that. You change the code, you run it, it works.

Automated versus Manual deployment:

The mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested in the build and test stages. Automation will help to ensure repeatability and consistency. The time required to provide a automated mechanism may not always be viable. If a manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient. Too many manual activities may slow down the release team and create resource or capacity issues that affect the service levels.

Many of the release and deployment activities are capable of a degree of automation. For example:

• Discovery tools aid release planning

• Discovery and installation software can check whether the required prerequisites and co-requisites are in place before installation of new or changed software components

• Automated builds can significantly reduce build and recovery times that in turn can resolve scheduling conflicts and delays

• Automated processes to load and update data to the configuration management system help to ensure the records are accurate and complete

• Installation procedures automatically update user and other information in the configuration management system