Investing in Dev, Test, Build, Configure, Deploy and Release

Introduction

I have recently been looking at ways to help improve the quality of some of my projects (this blog included). As such, I’ve had a play with some of the built-in features of Visual Studio (I am using Enterprise 2015 with Update 1, so depending on which version you are running, you may not see exactly what I see). I am also looking to build a pipeline that supports continuous integration and continuous deployment & release, as well as automation of testing. I am hoping that by building this ecosystem, a set of software development best practices will come to light for this project.

In this blog series, I will be using this blog application (that you are reading this on) as the subject, and walk through the steps I take in an effort to improve the overall quality of the project (including architecture and code design), and the quality of the release.

Currently, this project has no testing at all. All testing is performed manually in a development environment, then the project is published via Visual Studio (right click > publish), and copied manually onto the production server. Far from ideal, and has caused numerous issues in the past.

I have a number of areas of focus in the blog series, and it is designed to be a high-level pass over all areas (which I may revisit and add to at a later date). I will start by taking a closer look at some of the tools that Visual Studio gives developers to help promote better development practices. Next, my aim is add automated testing (starting with unit tests) to the project.

Once testing is in place, I will utilise the TFS 2015 Build system to create a Continuous Integration build to automate testing by building & testing on every checkin to source control (I will be using Team Foundation Version Control for this project, but expect a git-based workflow to follow). Once I have my CI build, I will then begin to look at a release build, and promote the build artifact through a number of release environments (deploying to each in turn) to production using the new TFS Release Management. By doing this, I will ensure that the release process to production becomes far more reliable. Any bugs introduced will have a much shorter feedback loop, and the process will be far less error-prone as everything that can be automated will be automated. It will also mean that the speed of a release cycle will be much shorter and faster, while becoming much less resource (me) intensive.

I’ve picked this project as an example as I know that the current development and release strategy is pretty poor, however a fairly common pattern in smaller software houses where TFS is not fully understood, and the pressure to automate is fleeting.

One final word before we jump in – I do not claim to know this inside out – there may well be better ways out there of doing what I am trying to achieve, and I am learning as I go – if you are someone that is lucky enough to have knowledge of these processes and you know of a better way of doing it, please share it with me so I can improve!

About the Blog Application

The Blog Application is a 3 tier ASP.Net 4.5 MVC 5 application consisting of a SQL database (2012), a Services layer (combined DAL and BLL), and a Web tier (MVC5). I am using Entity Framework 6 with Code First for the generation and connection to the database.

The Application is designed to be deployed per-configuration. There is a config key stored in the app settings that determines which resources (such as CSS, images, razor-view files) to load depending what blog is being displayed. For example, for this blog (www.trycatchexfinally.co.uk the asset code is set to “TCEF”. For blog.georgesbikeshed.co.uk the asset code is set to “GBS” and the database connection string is changed. Currently, this is controlled via Web.Config transforms, and I publish a copy of the application per blog.

Next: Improving Code Quality - Turning on Warnings as Errors



Tagged: DevOps, ALM,
Categorised: Application Lifecycle Management,
By:
On: