We(my project team) have prepared and using the following release process in my current organization.
Build Machine:-
The build machine is a dedicated physical or virtual machine whose whole purpose is to build you product/project। It should not use for development or for QA activities. here are some points to keep in mind when setting up build machine.
-> Keep the number of softwares installed on the build machine to a minimum.
-> More space
-> Machine should be fast
-> Remote access to this build machine for emergency access from out of work station.
Process to a release:-
The process is for web application we using for our project.
Three instances of the same code should be deployed for development team, QA team and the end client.
Dev Instance or Dev Server - Deployment for the dev team when the daily check ins made to the repository will be verified. This deployment can be updated twice or thrice in a day according to the number of commits made to the repository.
QA Instance or QA Server - This is the instance for the QA team. QA instance will be updated on every once in a week(say wednesday) The revision number of the code should be tracked by the QA team when this instance is updated (say it R). Dev team will send the list of all the features implemented or the bug fixes in the system from (say Monday). After Wednesday this instance will be updated only for the blocker and critical fixes. So some files in this instance will be on revision number greater than R and those needs to tracked also.
Staging Instance or Server Sever - This instance is meant for showcasing the system to the end clients. There should be no dummy data (like test post, or test user) on this instance. Sanity check on this instance has to be performed by giving some meaningful test data. The revision of this server should be same as of QA instance. By the end of day QA team will send the release notes for the revision R.
Make sure this is a process for my project. any one can set a process with some change as required in their project.
here the release note should be generated by QA lead for each build, this can be done by either pulling in the list of changes from the source control or by pulling in the task ids that have been implemented since the last build from whatever issue tracking system you are using.
