software release code and build development procedure
This document describes the process cycle in moving code from development to production.
The process to move code from development to production should take place in three steps, as follows
Staging Machine (Stage 1) (developers workstation)
- Build and test code on workstation
- Resolve all known bugs and issues on workstation
- Test code locally
- Test code on local network from another computer if possible
- Document code with a brief write up and store it in the p_materials folder on the ftp server.
- Name the documentation something descriptive, i.e., Remote Manager Summary.
- The type of documentation should include an overview of the application. It is not intended to cover everything, rather, give an explanation of the code, what it does, and the resources it needs to work. Some examples follow:
- If a Virtual web directory is needed
- If a SQL Backend is needed, if so how many databases.
- Connection string overview
- Dependent services
- Associated programs needed in-conjunction with the code, i.e., Data Generator, etc..
- Note any hard coded items
- Connection Strings
- Path or UNC Statements, or Mapped drives
- Usernames and Passwords associated with code
- Document any caveats
- Identify and special software or controls (3rd party) needed in addition to the code, for example
- ChartFX
- .Net Framework
- Special controls, i.e, Microsoft Tree controls
- Document and special services that are required
- SMTP mail server
- Web server
- FTP server
- SQL Server
- DNS
- ODBC
- DO NOT Name everything test. Instead give the application, code, database, etc. descriptive names. This will help make things more organized in the future when we don’t remember for example what the database name TEST was for
- Once the application/code is working without any problems prepare to move it to the development server
Development Server (Stage 2)
- Document all changes made to the dev server in a Change Control Form (CCF)
The CCF Template forms are located on the ftp server in the following folder:
\...\p_materials\change-control-forms-Template - Any user accounts that were created in Windows or SQL
- Where the application, service or code was installed, i.e., c:\program files\application1
- Any DSN’s that were created
- Any Databases that were created
- Any special components, software or code that was installed to make the application, service or code run, i.e.,
i. ChartFX
ii. Dundas Chart software
iii. Microsoft Tree controls
iv. Etc.
- Document any NTFS modifications that are needed
- Make sure you can rollback the server (remove application, service or code) if the application, service or code causes problems on the dev server.
- Several steps can be taken here to assure a clean rollback
- Contact the Systems Administrator for help if needed
- Prepare the dev sever for the application, service or code
- Create any needed databases
i. Create Local SQL server users on the dev server for application, service or code testing and try to give the SQL user as few rights as possible, i.e, do not make them part of the DBA group if possible.
ii. Do not call the database “TEST” instead give it a descriptive name.
- Create any needed DSN’s
- Install and configure the application, service or code on the dev server
- Test the application, service or code
- Test from computers inside the firewall
- Test from computers outside the firewall
- Test every feature and resolve all problems
- Have a colegue test the code
- Test the code from a computer that does not have development tools on it.
- Monitor the server performance before installing the application, service or code
- Monitor the server after the application, service or code is installed
i. Inform the Systems Administrator if the code is consuming server resources and it can not be resolved.
ii. Resolve the problem of consuming resources on the dev server before moving it to production
- Use specific domain users designed for connection strings before moving the code from the dev server to the production server
- Ask the System Administrator to create this user, if it has not been created and tested already
- Note that the domain users used for testing on the dev server will be the same users used on the production server. This will make the application, service or code portable in the domain.
- If you can not make the application, service or code run with domain accounts, run it as needed on the dev server with local accounts, but please resolve the problem before moving it to the production server as it will use domain accounts on the production server.
