Where Is This Code Going To Run? Part 6 - software development
Implementation
The purpose of the implementation phase is to release a fully tested and
 operational product to an end user or customer. The product should meet
 all the requirements that were documented in the BRD and pass the 
quality assurance and software testing phase before it can be released 
to a production environment. This phase is concerned with how to promote
 software in a controlled way from development to production. 
Environment Management
Environment management affects the software development lifecycle across
 phases. For organizational simplification this topic was centralized to
 this phase. It is important to note however that each of the previous 
phases will access one or more environments. 
Within a software organization different software environments are 
required for specific phases of the lifecycle development process. An 
environment is defined as the required infrastructure to successfully 
run an application (e.g. application server, database, middleware for 
communications etc.). Typically there are four environments - local 
development, development test, user acceptance testing (UAT) and 
production. 
Local development is primarily for the individual developer to work on 
their specific code. Each developer will have their own local 
development environment including their own database. Due to the 
sensitivity of the DIGS organizational data, the databases will be 
centralized and controlled. DIGS will use a strategy of hosting all 
development databases on a single server cluster and will provide unique
 ports to each developer to access their own database instance. This 
strategy explicitly mandates that developers are not allowed to install 
local databases on their physical machines in order to maintain data 
confidentiality. These environments are considered the most volatile and
 will change most frequently. Development test environment represent a 
shared development environment. This environment allows two or more 
developers to share the environment and determine how comingled 
functionality will perform. DIGS will also use the same strategy as 
local development for the development test databases. These two 
environments, local development and development test, will have the 
loosest access controls and are almost always owned by the development 
team. 
The UAT environment is tightly controlled and always mirrors production 
in terms of system setup and configuration. The UAT environment 
represents the “next” version of production. Business SMEs will access 
UAT and verify code works appropriately and will give final sign-off. 
After the code has been promoted from local development to development 
test and through UAT it will ultimately move into production. Production
 represents the live environment that end users access to perform their 
business functions. The production environment must be extremely tightly
 controlled in terms of access. The code must remain unchanged, and any 
user performing work in this environment must meet authentication and 
authorization requirements. In fact, server access should be limited to 
system administration and release engineer user accounts for both UAT 
and Production environments. 
Code movement between these environments is controlled by the release 
engineer. The release engineer will perform the task of collecting the 
appropriate version of code, all runtime dependencies and deploy the 
package to the appropriate environment.
Release Management
In order to be able to consistently perform the release the same way 
everytime the release engineer uses a deployment script. The deployment 
script automates the following steps: 
1.) Check out code from source repository.
2.) Versions (a.k.a. Tags) the code.
3.) Runs build script.
4.) Runs automated test framework script.
5.) Packages application for deployment.
6.) Moves deployment package to the appropriate runtime environment. 
7.) Executes start command on application server to initiate application.
Once the release engineer has deployed the code to production and the 
testers have verified the release, the implementation phase is complete 
and support phase may begin.