Your project plan was focused on ensuring you've met the your customer requirements... and you've had sufficient details in the plan to get your product delivered... on time. The devil is in the details. I work for a large university, and there is a complex requirement to introduce new production services into our environment. We actually have four development environments, and our projects move through these, which include...
- The local developer machines - developers control these so their status at any time could include a mix of code at different stages in the release cycle.
- Shared development environments which are in a more controlled state, with releases normally coordinated by project leads.
- Locked down acceptance environment. These are controlled by a different infrastructure group, and in order to be updated, would require instructions, and a self applying patch script. Code reviews are normally in place prior to releases in this environment, with coordination and hand-off by a project lead.
- Locked down production environments. Once the scripts have been proven on acceptance, the same scripts are executed by infrastructure teams on production, during a maintenance window, with developers verifying the update was applied successfully to each server.
- Document the deployment process, requirements, and any special needs.
- Document the performance profile, and requirements including storage performance.
- Provide pre-packaged updates.
- Document security requirements.
- Identify service name, and any necessary Verisign or Comodo certificates.
- Request DNS entries to support the new service.
- Identify firewall rules, and ports necessary to support the service.
- Request setup of any remote monitoring.
- Identify the maintenance windows.
- Test and submit any data integration processes, or other periodic maintenance processes.
- Perform necessary vulnerability scans on the servers to verify that only necessary ports are open, and that critical patches have been applied.
- Perform any applications scans to verify that you've addressed sanitizing rules to prevent cross site scripting and SQL injection.
- Test the application in each of your environments.
- Ensure that each page of your application verifies that sessions exist, and that you have a solid method for authentication. (Common include files or master pages help with this.)
- If you have external logging, ensure that it's in place.
- Identify your backup frequency, rotation, snapshot process, and any replication.
- Complete a disaster recovery plan, based on the requirements of the service.
- Have support trained, and in place to help users if they encounter issues.
- Have a period of open testing where your customers can test and provide feedback.
- Have a method to capture support requests, and forward them to a support group.
- Have escalation process in place for critical support issues or outages.
- Ensure you have antivirus in place as necessary.
- Line up and engage staff to develop training and documentation, and determine a method to deliver this in a cost effective manner.
- Obtain sign-off from any data stewards that may control the access to data you are delivering.
- Detail the final steps of turnover, and ensure that everyone agrees and can meet the expecations.
So, get in your running lane... line up on the blocks... ready... set... deploy!
