A typical package process includes:
· If the build deliverables had some significance (e.g., milestone, test, release), version control the deliverables from the build.
· Note: this may be a step at the end of the build process
· Identify any other known items (scripts, database, configuration, documents, etc.) that will create a package of deliverables that can be run in test (then production).
· Note: this may include version controlling some (or all) of these items preferably in the same code repository as the build deliverables.
· Collect the items together (e.g., ‘tar’ or similar function) into a identifiable draft package (items from the above 2 steps).
· Note: this step should be automated – it is iterative and will occur until the package is validated for release.
· Create a draft release notes to accompany the draft package
· Migrate the draft package into an appropriate test region for validation (functional, system, regression, performance, user acceptance).
· Validate the draft package. This is a test step.
· Incorporate (check-in) changes made to the draft package during testing into code repository so that the new ‘latest’ (a.k.a., release) package includes these changes.
Deploy is further defined as preparing for the release of the validated package, having a group of stakeholders review the readiness of the deliverables, and having a process in place to install and validate the release package once it is in production. In many cases, this is known as the release process.
Prior to performing a deployment process, a production infrastructure to host the release package must be in place. This may be in the form of a production system(s) or mechanism to install the release package onto media. Also, a change control process including a Change Control Board (CCB) should be in place to approve the release package into production.