One of the first steps I undertake when getting started with a new project is to think about how to automate the packaging and delivery of the software, first into a testing environment and then into a production environment. The details depend on exactly what we’re delivering and how that software product is being hosted, as well as getting an understanding of any existing processes or standards within the organization we’re working with. For the Account Center project, we were delivering a website with a frontend and backend on separate on-premise servers. The team we were working with did not have existing automation in place to build, test, package, or deliver these components, and their process to build out a server involved many pages documenting manual steps.
Initially, I was pointed towards this manual server setup path, with an indication that it wasn’t worth automating since it would only happen “a couple of times”. While we could have continued down that path, I foresaw the potential for drift in the configuration of different environments and knew that we would end up repeating “a couple of times” over and over. By the end of the project, one of the highlights from this team was the ease of deploying the software onto new servers (our scripts ended up being used to configure over a dozen servers for the various environments and tiers within the application).
Since this was a first step for this organization, I avoided introducing new tools that would need to be validated, approved, monitored, and maintained, and instead opted for a simpler approach of plain PowerShell scripts to maintain and manage the configuration of each service within the application.
This organization used Azure DevOps for storing source code, so we developed Azure DevOps Pipelines to build, test and package that code, and then additional pipelines to take those packaged assets and deploy them (automatically for the shared dev/test environment, after a manual approval for higher environments). We also worked with the security team to pilot adding security scanning tools into these pipelines.
I’m proud of the work we were able to accomplish, especially since the team we were working with did not have any of these practices in place. I’m hopeful that this experience will push all of those involved to invest more towards reaping the benefits of delivery automation and other DevOps capabilities in their future projects. DevOps practices allow teams to move more quickly and meet their organizations’ needs without getting stuck in an error-prone manual test/deploy/fix cycle.