A major part of my job is deploying custom applications, and ensuring they are deployed correctly. They are a variety of IIS applications and Windows services, and the application as a whole is designed to be able to scale at any part of the data path. We also have multiple environments of this application that each have their own purpose, whether it’s customer facing, or internal engineering and test environments. It’s easy to see then, that not one of these environments will need to scale in the same places. There are 43 different web apps and services that make this application work, and across the 8 environments and 400 VMs, we have over 900 individual installations. Adding to that the fact that different environments will be running different versions for testing purposes, it’s easy to see that managing this environment needed an automated method to ensure the applications are installed correctly.
When I first joined this team, the environments were much smaller in every sense. There were fewer servers, fewer applications, fewer environments, and deployments occurred less frequently. At the time, the team had a small set of PowerShell scripts that were used simply to deploy the applications. There was a lot of hard-coded logic in the scripts, because not a lot had been changing. This worked well, but when new servers needed to be added, or new applications were added, the scripts needed to change. There was also no tracking of what was deployed. As a new system admin, I thought this was a great chance to enhance my knowledge of PowerShell and make my job easier and the results more consistent. The result was a PowerShell module with a SQL backend that tracked and deployed these applications, and was easily scalable as things changed in the applications or the environments.
Over the next few posts, I’ll be explaining the logic behind the different functions within the module, the database design, and the future plans for the module.