Question

I have these constant battles with my colleagues regarding composition of deployment documentation.

Everyone agrees that the documentation is necessary. Not everyone can find common ground on what level of detail should go into this especially differentiating between large releases, bug-fixes and enhancements.

What have you found works best for you?

Was it helpful?

Solution

If your purpose of the documentation is to ensure the code is deployed in a repeatable manner, then the following would be the minimum recommended practice:

  1. A summary of what the release is about, what changed, version, where the solution file can be found etc.
  2. List possible dependencies
  3. Detailed deployment procedures
  4. Database changes or scripts required for the install
  5. Configuration summary on how the application is configured.
  6. Key functional test that can be run to verify the install as operational.
  7. Rollback procedure - if required.

OTHER TIPS

I have found that building a tool that allows for a one click deployment is much better than thorough deployment documentation.

What's the purpose of your documentation? Start from there and figure what meets that goal.

For us, our goal was to enable someone entirely new to the group to be able to execute a new or updated deployment for a few different systems. We we're operating a soup-to-nuts kind of operation -- windows services, cron jobs, database backups, web site updates, etc.

In each case, the level of detail was based on the system and what a new team member would need to execute updates and fresh deployments.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top