Creating a deployment pipeline

20 Oct 2017

Release management process

This topic discusses the environments used in the release management process for a WebApp solution. As with any enterprise software solution, you should follow established software release management guidelines when you develop and release a solution. This process should include the following distinct stages:

Ideally, you should complete each stage in the release management process in a discrete environment, separate from the other environments. Realistically, you may have to combine one or more of the environments due to hardware, time, or other resource constraints. At a bare minimum you should separate the production environment from the other environments.

Development

The projects are created in the development environment. Typically developers should have their own development computer (physical or virtual) with the necessary software installed. You should install the following software on the computers used in the development environment:

Testing

Unit testing can be completed in a Virtual Server environment. You should, however, conduct your performance testing in a physical environment with hardware and software that is identical to the production environment.

The testing environment should be used as a “internal testing” Environment

Staging

You typically use the staging environment to “unit test” the actual deployment of the solution. The software installed in the staging environment should closely match the software installed in the production environment. It may, however, be acceptable to use computers running Virtual Server in the staging environment since this environment is not to be used for measuring performance.

The testing environment should be used as a “external testing” environment

Production

The production environment is the “live” environment that will host the running solution. The production environment is the final endpoint in the release management process and should only host applications that have previously undergone development, unit testing, load testing, and staging in the other environments. Thorough unit testing, load testing, and staging beforehand will help ensure maximum performance and uptime for the application in the production environment.

Environment Configuration

You should store all sensitive information in ‘env.php’ and add the file to your .gitignore, so that you don’t accidentally commit to source control.

Just rename the file ‘env.example.php’ to ‘env.php’

Usage

The env.php file is generally kept out of version control since it can contain sensitive API keys and passwords.

A separate ´env.example.php´ file is created with all the required environment variables defined except for the sensitive ones, which are either user-supplied for their own development environments or are communicated elsewhere to project collaborators.

The project collaborators then independently copy the env.example.php file to a local env.php and ensure all the settings are correct for their local environment, filling in the secret keys or providing their own values when necessary.

In this usage, the config/env.php file should be added to the project’s .gitignore file so that it will never be committed by collaborators.

This usage ensures that no sensitive passwords or API keys will ever be in the version control history so there is less risk of a security breach, and production values will never have to be shared with all project collaborators.

Best practice

In testing, staging and production environment you should place the env.php outside the application root directory. By placing the env.php outside the app, you are protecting the configuration from beeing accidently overwritten. This makes it possible to update to a new version without worrying about the environment specific configuration.

By default the application is looking for a env.php outside the app. If the file not exists the application is looking for a file in ´config/env.php´.

Pros:

Other solution

Using .env files with phpdotenv is not recommended because of security reasons.

Read more: Environment Variables Considered Harmful for Your Secrets

Continuously delivering

This is the pipleline:

Deployment pipeline

COMMIT > BUILD > TEST >| DEPLOY

Generate an artifact

  1. Check out master branch
  2. Create a env.php file for each environment
    • Only one artifact for all environments (prod, staging, test, etc).
    • The env.php file contains the secret environment parameters like database credentials (DSN) and is not part of the artifact.
  3. Fetch the PHP dependencies (composer install/update)
  4. Fetch the JS dependencies (webpack) [optional]
  5. Generate the assets (LESS, SASS) [optional]
  6. Run the unit tests
  7. Generate the artifact (zip file)
    • The artifact is a bundle of your release with php, vendor, js and css files
    • Build an artifact (zip) with Apache Ant (build.xml), Jenkins, within your IDE or command line
    • Discard unnececarry folders and file from the artifact (.git, tests/, sass, less)

Deployment

Deploy the new release (with ansible deploy.yml) or with a php script like (deploy.php)

Steps (manual or by script):

Books

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Videos

Javier Lopez - Continuously delivering PHP projects