Here at Enable, we utilise automation throughout the software development life cycle to make the process of applying and deploying changes to our applications consistent and reliable. This ensures that engineers do not spend unnecessary time resolving issues with their local environments, that making and deploying changes to our applications is as efficient and consistent as possible, and that any mistakes are picked up early (and often automatically); before they make it into our production environments. Using automation also promotes and enforces standardized processes and practices among the team to allow smooth collaboration between engineers.

1. Solution setup
   The end-to-end process of making a change to a solution starts with setting up the solution locally. We use solution setup scripts to get the latest version of the code from source control, install any dependencies, and ensure that any required local databases are configured correctly. This means we can reliably get each engineer's local environment into a consistent state before each project, and engineers can spend more time on build tasks.
2. Committing a code change
   Once a change has been made and tested locally, it will then be committed to source control (typically to a feature branch). We utilise Git Hooks, which are installed as part of the solution setup process, to ensure that the format of the commit message meets Enable's standards. Writing high quality, standardized commit messages makes collaborating with other engineers using Git a lot easier and helps the team to understand what changes were made to a solution, and why those changes were made. If a commit does not meet Enable's standards, a message is displayed informing the engineer what changes they need to make to format the commit message correctly.
3. Code review process
   When merging a change into a branch which is associated with either a pre-production or production environment, we use pull requests to ensure the quality of the code being committed. A pull request is an opportunity for an engineer to review the changes which they are committing, and will typically be reviewed by another engineer. As part of the pull request, the engineer is alerted to any merge conflicts between the current branch and the branch into which they are merging. A CI (Continuous Integration) build is also run to ensure that the build will succeed when the changes are merged into the target branch. Preventing failing CI builds is essential to ensure the changes made by one engineer do not impact the productivity of their team, or any other engineers working on the same solution.
4. Continuous integration
   Before a change can be deployed to its target environment, the CI build for the associated branch must succeed. This doesn't just ensure that the solution itself compiles, but also ensures that the application continues to fulfil its business requirements. We follow the test-driven development pattern to produce a suite of unit tests for a solution, which validate that the code satisfies, and will continue to satisfy, the business requirements of the application. Should a change be made that changes the functionality of the application in such a way that it no longer meets the business requirements, we will be alerted to this in the form of failing tests. The CI build will also produce the packages which are required to deploy the solution and run linting (analysis of code format and style) to ensure that the code meets Enable's standards.
   
   Utilizing CI builds also allows us to monitor builds across our solutions for any regressions in the form of an increase in warnings or a decrease in the number of tests passing.

5. Deployment
   Once the CI build has succeeded for the relevant branch, the next step is to deploy it to the target environment. At Enable, we utilise an automated deployment process to ensure deploying a solution is simple, reliable and consistent. This reduces the time spent deploying a solution, allowing more time to be spent developing, and increases the robustness of the process, as once a deployment process is configured and tested it can be repeated with ease. Releasing software in this way is restricted based on permissions to ensure any deployments do not affect our customers' ability to use our software. For example, this can prevent us from making a deployment to some live environments during the working day, or without first seeking approval from our IT team.

Automation at Enable

Using automation vastly improves and streamlines our development process in multiple ways, enabling engineers to spend the maximum possible time focussed on developing software which is of a consistent, high quality. This software can then be built and deployed using a process which requires minimal intervention and configuration after initial setup, reducing the likelihood and impact of human error, but which can be relied upon to consistently execute the desired task as necessary and automatically report any issues as and when they occur.