Software deployments as changes

[KrissAkabusi]

Hi all, hoping for a bit of advice

So, we are looking to amend our process to bring Software deployments under the change process. At the moment, we have a very distinct dichotomy - Change for infrastructure - release for software. This goes back to before my time here.

In my opinion, Software changes is a type of change like all others - and thus should be a part of a planned release (but as an approved change).

We are changing a large amount of software every day, with very quick turnaround, and as things stand, i cant possibly see how software could realistically be subject to the same change process to allow the speed of turnaround required by the customer.

Does anyone have any experience with this - i.e. how software changes are assessed, and how you have avoided massively slowing down the required release velocity by over-assessing the component changes.

[Diarmid]

Without prejudice as to the nature of "changing a large amount of software every day", you must always design your change process to meet all your requirements, including timescales, authorisation, documentation, testing, validation verification, regression planning and so on. It should be easy to make things like authorizarion, verification and regression palnning very slick with that kind of frequency. With the rest it is down to balancing risk against benefit and that is what you need to agree with your customer(s).

Some of the areas you have to accomodate are:

errors in released code
errors in the release process
changes not delivering the desired benefit
changes impacting on other services and systems
changes that require an environment change (e.g. additional OS patch - with its impact on other systems)
changes that affect capacity or performance
impact on other planned changes

This is not complete by any means, but it is a good bit of what you have to design into an expeditious change process - or any change process for that matter.

The answer to your last sentence is that you do not over-assess component changes, you appropriately assess them and you define what is appropriate. There is nothing heavyweight about change management; it is always about doing things the right way for your requirements. It is all about protecting the stability and integrity of the service environment, the services [and the change manager] and managing the risks.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718