Release Management

Release and Configuration Management

Release Management. Our primary goals of release management are to ensure compatibility, enable tracking, revert changes if necessary, mitigate risk, transfer knowledge, and experience no regression errors. Particularly when there are multiple developers working on the same file, we want to manage conflicts and avoid code collisions where one developer’s code accidentally overwrites another developer’s code. Release management, configuration management, continuous integration, and continuous deployment is all part of DevOps and workflow engineering.

Release Workflow. We use two separate environments – development and staging – to perform testing and quality assurance over the code that will be released to the production server. Some people confuse the hosting environment with the workflow branches. They are two separate things.  Confusion probably occurs because we often name both a type of branch and a server environment after development, i.e., there is often a development branch and a development environment. These are totally different.

The development environment is used to review and test new features that are still under implementation. The development branch is part of the Git workflow where features are integrated. Fortunately, some teams with a continuous integration (CI) mindset who integrate several times a day or week are abandoning the concept of a development branch. Instead of deploying a branch, they are deploying a commit.

The staging environment is used to test the release candidates before they are deployed to production. In addition, we have local environments that we use on our local computers to develop and test our work individually. We use Docker containers to ensure that all those environments have the same server settings, and so mitigate issues during deployment.

DevOps. Most of the key best practices that help automate and streamline the software development and release management process involve proper tooling. In addition, a fundamental best practice is small frequent releases because each deployment is less risky, which helps the team identify and resolve issues faster by reducing or eliminating variables.

Tools. To support website operations and maintenance, development and upgrades, testing and remediation, documentation, and migration, we would likely leverage the following tools JIRA, Slack, Total Validator, New Relic, Balsamiq, Marvel, Colour Contrast Analyzer, Confluence, Cloudflare, JAWS, Git, GitKraken, SmartGit, GitHub, GoToMeeting, Tempo, LastPass, Heroku, Docker, Snagit, Jenkins, PHPUnit, Behat, BLT (Build and Launch Tool), and Drush.

Git best practices. We use the following best practices to develop new features, or fix critical issues in the live site without unintentionally affecting other areas of the project.

  • Main branches. Typically, we use two main branches – the master branch and a develop branch. The master branch always reflects a production ready state and releases are tagged from master. The develop branch is an integration branch. We perform automated testing on this branch and it always reflects a state with the latest delivered changes and updates for the next release. Branches are never modified directly.
  • Supporting branches. These include feature branches, release branches, and hotfix branches. Feature branches are created from the develop branch and are used to develop new features. Release branches are also created from the develop branch, supports preparation of a new production release, and allows the develop branch to receive updates. The hotfix branch is created from the master branch and is used when changes on develop are not release-ready and a fix to production is required that cannot wait until the upcoming release is stable.
  • Branching and merging. The feature branches branch off from develop and merge back into develop. Release branches branch off from develop and merge back into develop and master. Hotfix branches branch off master and merge back into develop and master.
  • Pull requests. Pull requests are a feature that makes it easier for developers to collaborate in Git repositories. They let you tell others about changes you’ve pushed to a repository and discuss proposed changes before integrating them into the official project. This is a great way to keep everybody in the team posted about any release and avoid disconnections. This also gives the responsibility to the entire team about the release, not just to one individual.