RedGage is the best way to earn real money from your photos, videos, blogs, and links.

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.

Thanks. Your rating has been saved.
You've added this content to your favorites.
$0.00
Make money on RedGage just like jboeglen!