Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.
Eli's Continuous Delivery Project
In early November I decided to implement a small Continuous Delivery project to give me a foundation for future projects and to get some more experience with build processes and automation. I chose the ASP.Net MVC MusicStore tutorial project as my guinnea pig and built a framework around it.
Continuous Delivery focuses on standardizing the environments and processes for product delivery, with an aim to create a clear and consistent process from committing new code to having a deliverable product. Creating a consistent process reduces variability and risks involved with manual deployment, ensures all "ready to be released" products meet our build and testing standards, creates a faster feedback loop so that problems are detected sooner (and thus can be fixed cheaper), and adds a level of auditability that rarely exists with manual deployment processes.
These are the posts that I created out of the work log/notes I took while implementing the project, starting with a general overview and then working through the details.
- Starting a Continuous Delivery Project
- Setting up the Continuous Integration stage
- Making MVC Music Store Testable
- Incorporating Unit Tests in the CI stage
- Automated Deploy and Smoke Test
- Automated Interface/Acceptance Testing stage
- Dashboard, QA and Production Deployment stage
- Using Using SpecFlow to drive Selenium WebDriver Tests
- Automatically Version Control Your Jenkins Configuration
- Incorporating Load Testing into my Continuous Delivery Pipeline
As I continue to use this project for new and interesting experiments, I'll add the links above, even if they don't have much to do with Continuous Delivery itself.
This section is relevant live links for code and deployed artifacts.
- 'Production' (Build Version Number in bottom left corner)
- MVCMusicStore.Main Repository - Main Mercurial Repository on BitBucket
- MVCMusicStore.InterfaceTests Repository - Automated Test Project Mercurial Repository on BitBucket
This is a brief list of items that have been added after the initial blog series was completed. Changes here may be reflected in various code repositories or on the 'production' site.
- Centralized Settings - Converted all jobs to use a settings file for passwords, server names, and URLs using Jenkins EnvFile Plugin
- Versioned Job Configs - Added all Jenkins configs to a Hg repository and setup a job to automatically push updated configs to central Hg repository (currently private because I'm paraniod I'll accidentally check in some credentials)
- Static Code Analysis - Added a Gendarme run and the Jenkins Violations plugin to capture the results
- Additional Analysis via Static Analysis plugins
- BDD Tests - Added SpecFlow to the InterfaceTests project and started building out more extensive coverage
- Load Tests - Adding a load testing build step to load test a deployed site and graph results over time
I'll continue to add items as I do them and may post some later blog posts for some of these.
The project required the use of a number of different technologies along the way. This is a list of the main ones:
- VMWare Server
- Hosted the Build Server and Beta Server
- Windows 2008 Server
- OS for the Build and Beta servers
- ASP.Net MVC 3
- Development stage, to get more practice with MVC
- Entity Framework
- Development stage, I don't really care for entity framework, so I'm trying to use it more
- MS Test
- Development stage, I like MS Test for the dev stage because of it's integration into Visual Studio
- Source Control, local and BitBucket
- Jenkins, I'd heard good things about it, lots of plugins, I'd only ever used TFS in the past for CI and Chrissie already has posts on TeamCity :)
- MS Build
- CI Stage, MS Build to build the code, transform configurations, and create the deployment package
- IIS 7
- Deploy Steps, IIS 7 supports the new WebDeploy capabilities, which will make deployment much easier
- MS Deploy
- Deploy Steps, I haven't had an opportunity to do more than push the "Deploy" button in WebMatrix, looking forward to getting more in depth with WebDeploy
- Deploy Steps, A small vbscript capable of using XMLHTTP to make raw HTTP GET requests (potentially switch to PowerShell later)
- Automated Test Stage, Platform and testrunner for the automated interface tests
- Selenium WebDriver
- Automated Test Stage, Automated interface testing to be driven by the Nunit framework
- Build Pipeline Plugin
- Dashboard, There is a build pipeline plugin for Jenkins that I intend to try out
- Communications, I'll be using twitter for status notifications at each stage
This is the list of the Jenkins plugins used over the course of the project.
- Build Pipeline Plugin
- Copy Artifacts Plugin
- Green Balls Plugin - Displays Successful jobs with Green light rather than Blue
- Mercurial Plugin
- MSBuild Plugin
- MS Test Plugin
- NUnit Plugin
- Parameterized Trigger Plugin
- Twitter Plugin
The version of Jenkins updated several times during the post, the latest version used with the blog post series was 1.442 (though I have another update to apply tonight to 1.443).
What I Skipped
There were several places I skipped over things that would be part of a production pipeline. The notable items are:
- Administrator Accounts - I am using local administrator accounts for deployments due to the time limitations and my level of annoyance with MSDeploy
- Database Deployment - The database is using Compact SQL and checked in and deployed as part of the project - this allowed me to skip database deployments but wouldn't be workable in a production environment
- Limited Test Coverage - I created enough tests to be used in their respective stages, but unit test coverage was limited and I can't bring myself to call the interface tests acceptance tests because they were even more limited
- Configuration Management - There isn't any, mostly because of the shortcut with Database Deployment