The Timeout digital department has over 30 technical members of staff including backend developers, frontend developers, a QA team, a DevOps team and a Product team. Due to it being a global platform, there were constantly many different projects and sprints happening concurrently.

To increase productivity, the journey from the local development environment to the production environment needed to be optimised to be as smooth, scalable and automated as possible.

One of the bottlenecks identified was the shortage of QA environments. Even when all 15 QA environments were utilised, there was still the process of agreeing which features from which projects can be built to which QA box at what time. WIth so many new features constantly being developed in addition to bug fixes, the model of using long-live machines for QA boxes needed to be reviewed. To solve this problem, a system was introduced that allowed every pull request to automatically create its own QA environment in the AWS cloud. The process was as follows:

• Develop the feature locally
• Push to main repository and create pull request on Github
• Automated tests automatically start running on Jenkins. This includes BDD tests, backend and frontend unit tests
• Pull request page on Github is then updated with results of the test suite
• If passed, a phrase (similar to) 'build-this-to-qa-now' is entered into the comments of the pull request by the user. This then triggers a pipeline in Jenkins that spins up a brand new QA environment containing the code from the pull request. The environment is spun up using Ansibe and AWS. Once the environment is ready to use, a message containing the URL to the new QA environment running the version of the app built using the pull request code is injected into the Github comments
• Developers, QA and Product teams can then visit the environment and perform manual tests to ensure everything is working as specified
• Once in agreement the pull request is merged into the master branch and closed
• Once the pull request is merged into the master branch, another pipeline is automatically started. This pipeline runs all automated tests and builds the master branch to a QA box. This is to test for the absence of post-merge master branch issues.

Using this approach, the demand for the existing long-live QA environments was dramatically reduced. In addition, more accurate, staging-environment-ready work was produced. This was due to all people involved receiving faster feedback by being able to test the features in a QA environment at a much earlier stage in the process.

Technologies Used

	Amazon S3		Amazon EC2		Amazon Route 53
	Selenium Grid		Ansible		Jenkins
	Symfony 2		MySQL		Behat
	Karma		PHPUnit		Github
	Wiremock