The Local Setup

    Sarah is a new developer at the company. She has been assigned a task in the project where the third-party API package switcher is having some problems. She reads through the ticket assigned to her by the Project Manager. The ticket directs her to some documentation regarding the package switcher functionality where she learns that it is used in both the front-end application and user application environments. Both environments make an API request to the same REST application endpoint, but each has different methods of authentication into the REST application.

    Sarah has never worked on the project before so a fellow developer shows her the documentation for how to set a new local environment. The documentation indicates that she must:

1. Clone a repo of a Homestead setup
2. Create a virtual environment
3. Point the Homestead application at the virtual environment
4. Run a single command in the terminal

    This one command creates a full project setup with the front-end application, the REST application, and the user application environments. It also automatically spins up a new user application site within the environment and provides a URL that she can use to access this local user application site when it is complete.

Investigation and Coding

    Now Sarah can begin her investigation into the ticket created. She can locate the root of the problem in the REST application. She identifies that a third-party API has changed slightly. She checks the last run integration tests to see if any error was reported. If no errors were found she reruns them and confirms that her diagnosis is correct.

    She first uses TDD principles to ensure the change she makes to the REST application works and she runs her new tests to be sure of the change. She then changes the third-party mock API tests in the REST application. Finally, she reruns the full test suite to verify no other functionality in the application is affected by the changes. If anything is, she then makes the necessary changes using TDD principles once again.

All the Tests!!!

    She commits her changes to the REST repository and a Continuous Integration system runs each application’s tests as well as all of the integration tests. Because the integration tests will fail as we saw before, the application will not deploy and will email the developers and the PM on the project to let them know that the build is broken.

    Next, she changes the integration tests to account for the change in the third-party API. She then runs her new integration tests to ensure they are working with the third-party API. Finally, she runs the full suite of integration tests to ensure her change to the REST application is compatible with how the front-end application and user applications use the package switcher endpoint.

    When Sarah commits her changes the CI system runs all of the tests again and this time they all pass. The CI system then informs the Continuous Deployment system that the build is passing and the changes can be deployed. All of the developers and the PM are once again emailed to let them know that the build is now once again working.

The Deployment

    There are two environments on the production system: the “green”, currently active environment, and the “blue”, currently inactive environment. Both are identical at this point, but when users hit the system they only actually interact with the “green” environment currently. One environment can easily be swapped out for another at a moment’s notice with zero downtime. 

The CD system deploys the application to the “blue” environment. Once the deployment to the “blue” environment is successful it swaps it out for the “green” environment. The “green” environment, without the changes, now becomes the inactive environment, and the “blue” environment, with the changes, becomes the active environment. 

    A suite of simple tests are run to ensure that the application is running as expected in production. If it is running with everything looking good, then an email is sent to Sarah to double-check. If she indicates that everything is good she simply clicks a button in the CD system and the change is also deployed to the “green” environment, but no swap is made this time since we don’t need to.

    If however an issue is identified either by the automated production tests or by the user then a rollback occurs where the “green” environment once again becomes the active one, since it has not had any changes be made to it yet. If the CD system detects the problem it will automatically perform the “rollback” itself. If Sarah detects the problem then she simply has to press a button in the CD system to perform the “rollback”. Once a “rollback” occurs all of the developers and the PM are notified by email. The “blue” environment still has the changes deployed so that, if needed, the developer can investigate what the issue was. The developer is responsible for also clicking the button to revert the “blue” environment to the last known working state. If they do not, then after 30 minutes, unless intervention occurs, the system will automatically revert the “blue” environment to the last known working state.

Conclusion

Another developer at the company asked me to write this for what an ideal process might look like for a specific project we are working on. Feel free to reach out on Twitter if you have any questions or recommendations for what I have come up with.