When copy and paste for deployment becomes untenable (YES! It never was, I know!)

The software deployment strategy at work is really bad. I feel bad about it because it’s mostly my fault: either I have not installed good strategies, or I have allowed bad practises to persist. We also do active development work in production, but that is a separate battle (and I don’t really feel like having it any time soon).

I could blame it on other people and say I know better, but I am the primary developer for the location so I need to set a better example and provide the tools to help improve the situation.

I am going to focus 3 different application types in our Windows environment: desktop apps, web apps, and services. Our current deployment strategy predominantly involves copying files to our share server from a development machine after a release build then copying those same files down the machines running said app.

Desktop

All of our current desktop applications are Windows Forms built with C#.NET. In order to update the project must be compiled (usually in release mode), the build results are copied to a share path specific to the application, the application is closed, the local application files are replaced, then the application can be restarted. I have made this simpler for many of our scenarios by creating a tool that performs the update on application close.

Web

We have 2 main web application types: ASP.NET Core and legacy ASP classic. For the ASP classic sites, any new/changed .asp files in the application path are copied from the dev server to prod and they immediately become active. The .NET sites are little more complicated… as they must be compiled/published then resulting files (minus any configuration files) are copied to the server (usually the application pool must be stopped during and restarted after).

Services

The only services we currently build ourselves are Windows only services that make use of the full .NET framework. In order to update the project must be compiled (usually in release mode)

Setting up Jenkins

Jenkins was recommended to me as good starting tool for automating build, test, and deployment at the Indy.Code() conference I recently attended. I setup a Jenkins instance on one of our development VMs to begin testing following the guide on BlazeMeter and using the OpenJDK 11 OpenJ9 JVM on AdoptOpenJDK rather than worry about Oracle licensing issues.