Release Management: DSL

[JohanCelis]

I'm working for a small company that makes a few products we try to sell together with our implementation services.

When a new version is released it goes through a release management process and the actual product is stored in electronical form.

I would like to start storing the product deliverables (installation package, user documentation, technical documentation, source code,...) in a physical place. I was thinking about a vault in a bank.
This information would be burnt on a DVD/CD for each release and stored in a vault at a local bank.
A second copy would be stored in the office in a locked cabinet.
The electronical version would still be available to internal people for testing and stuff.

Together with the deliverables I also want to store the tools that is required to compile/build the product.

If I look at what I'm trying to do here it looks a lot like setting up an "Escrow" agreement.

I was hoping to get some different views on my ideas here and in the meanwhile I also have some questions.

1. What are the advantages of storing the deliverables in two physical locations (this is probably obvious to most people but I need to convince the people in the team)
2. Am I going to far with trying to store the development tools together wit hthe source code and stuff (the source code is our biggest asset and I want to protect it)
3. Our product team regularly releases new versions. Will this release management procedure be to heavy for this kind of frequency (2 to 3 releases per month)

Any feedback is appreciated.

Johan Celis

[Jinx003]

Hi Johan Celis,

This is my point of view.

1. What are the advantages of storing the deliverables in two physical locations (this is probably obvious to most people but I need to convince the people in the team)

The main advantage of having it stored in two different locations provides contigency for the media. This will help you in a DR (Disaster Recovery) operation. But again, it might be cumbersome to track the inward and outward movements of media in the DSL. As long as you have sufficient resource to the activity, you may do this.

2. Am I going to far with trying to store the development tools together wit hthe source code and stuff (the source code is our biggest asset and I want to protect it)

Well, I wouldnt consider it as going too far. Similar to point 1, in case of a DR, you may be able to bring back your operations faster if you have all the software media stored together.

3. Our product team regularly releases new versions. Will this release management procedure be to heavy for this kind of frequency (2 to 3 releases per month)

Hmm.. well, it might be a bit heavy unless you have the process well established and have sufficient resources. Considering your point that its a small company, it might be a bit hard.

[JohanCelis]

Hi Jinx003,

Thanks for your reply.

Johan

[Bally]

Hi Johan,

Interesting post, Jinx003 makes some excellent points, a few extras to consider.

1. In terms of convincing your team, this will be the hardest objective to achieve, designing processess is easy. You need to change the culture of the team to a service mentality and this is ALWAYS the hardest part of a process change. They will be interested in the 'what’s in it for me', you have to sell all the benefits associated with your new process, this may be in time saved if things go wrong, financial, etc.

Involve them in designing the process to give them ownership and buy-in. They will have good ideas to offer, maybe appoint one of them the owner of the process, empower them and drive it with enthusiasm you really will be surprised at what they will come up with given the chance. Talk about it all the time, measure them against it in their appraisal, stick it in the induction package...etc...

Don’t forget your DR plans must be dictated by the business continuity plans of your organization. What you are doing shouldn't be in isolation.

2. No, great idea....but don't forget the licenses....obviously you say but I have seen it done. If you are using the offsite storage for recovery, consider all the components needed to get up and running. H/W S/W docs, licenses, installation documentation, contact numbers, etc.


3. If you embed the process it becomes 'the way'. This comes back to some of my comments in (1). If the process is simple and designed by the people using it they tend not to circumnavigate their own work. make sure you review it regularly so it's relevant to your business and fit for purpose.

Good luck,
Bally