On-Prem .NET Deployment and Testing: A Journey to Improvement

Inheriting a legacy application can feel like stepping into a whirlwind. Recently, I found myself in this exact situation, taking over a .NET Framework 4.6.2 MVC E-Commerce Application along with several in-house utilities. As the sole web developer in a company that has a mix of systems and software developers, the responsibility felt daunting. With around 2000 orders processed daily, totaling approximately $100k, the stakes were high, and the deployment process was surprisingly primitive.

The Current State of Deployment

Currently, the deployment of our application is a manual process, relying heavily on copy-paste actions to transfer files to two on-premises IIS servers. The workflow is as follows:

1. Publish the app to a local /Temp folder, ensuring to delete the /images folder and web.config to avoid overwriting production settings.
2. Remote into the on-prem web server.
3. Stop synchronization between the two web servers.
4. Copy and paste files from the local /Temp to the web server’s /Temp folder.
5. Move the files from the /Temp folder to the application’s directory, overwriting existing code/files.
6. Restart the synchronization and confirm the server is operational.

With no testing in place, it seems almost reckless that such a critical application hinges on the accuracy of manual file transfers. I knew it was time to make some changes.

The Need for Improvement

Given my background primarily in Ruby on Rails and JavaScript, the transition to improving a .NET application was both exciting and intimidating. My initial thoughts were to prioritize testing, particularly integration tests, due to the complex interdependencies within the mature codebase. This led me to consider which testing framework might be the best fit: NUnit, xUnit, or MSTest?

Choosing the Right Testing Framework

From the community feedback, xUnit appears to be the modern choice for new .NET projects, but if NUnit is already integrated into the existing project, it’s a solid option. My focus will be to start implementing tests that ensure the application behaves as expected, particularly around the core functionalities.

Automating the Deployment Process

One of the most pressing issues is the manual deployment process. To streamline this, I plan to start building PowerShell scripts to automate the workflow. Instead of relying on manual actions, the scripts can be part of the codebase for building and deploying the application. Here’s how I envision the process:

1. Create PowerShell Scripts:

   • A build.ps script to handle the build process.
   • A deploy.ps script to manage the deployment.

2. Secrets Management:

   • Utilize a secrets manager to handle sensitive information like usernames and passwords. This can ensure that credentials are stored securely and accessed only when necessary.

3. Documentation:

   • Create a clear guide on how to run the scripts and where to retrieve the required secrets. This could look something like:

     Run build.ps
     Get username and password from [www.secretstore.com](http://www.secretstore.com) / KeePass / etc.
     Run deploy.ps "username" "password" "ip"
     

By leveraging PowerShell, I can automate repetitive tasks and reduce the risk of human error during deployments.

Exploring CI/CD Tools

As I look to improve the overall development process, integrating Continuous Integration and Continuous Deployment (CI/CD) practices is essential. While I have experience with Ansible for AWS provisioning, I’m considering tools that would facilitate smoother deployments in our on-prem environment.

Azure DevOps (ADO) as a Starting Point

One suggestion I’ve received is to explore Azure DevOps, which supports TFS and offers a straightforward migration path to git. If MSDN subscriptions are available, it can provide a cost-effective solution with hosted build agents. ADO allows the use of on-prem agents to manage deployments via YAML pipelines, providing the ability to include approval gates—a critical feature when business stakeholders need to sign off on changes.

GitHub Actions as an Alternative

Alternatively, GitHub Actions is also a viable option. It can enable seamless CI/CD processes, and using local GitHub runners can support on-prem deployments. The choice between ADO and GitHub may ultimately depend on the budget and existing tools in use within the company.

Overcoming Challenges and Building Team Buy-In

One of the biggest challenges will be gaining buy-in from the existing team and management. Many team members are accustomed to their established workflows, and change can be met with resistance. I recognize that while the technical aspects are crucial, navigating the politics of the workplace is equally important. I plan to approach this gradually—starting with small, manageable changes and demonstrating the value of improvements over time.

Conclusion: A Path Forward

While the current state of our deployment and testing processes leaves much to be