Monday, August 08, 2016

Pitfalls of Continuous Delivery - Austin .Net Users Group

Jeffrey Palermo, founder of, spoke to 35 people at the August .Net User's Group (

ClearMeasure has a sample solution:

My notes:
Do not set up a shared database server for the team.  It's the same as a global variable that can get hammered.
Use independent non-shared databases created from a script in source control.
To facilitate continuous delivery with no downtime, add columns to a database so older and newer version of your code can run. 
If using a database table as a shared API between systems, use a separate sharable table.
Do not put more than on application in one solution because branching and versioning are coupled.
Share code between teams via a nuget package.
Do not let a build remain broken - fixing the build is everyone top priority.
Put server configuration into version control.
Do not clone virtual machines to create a new test machine, use versioned scripts.
Everything should go in source control - except passwords.  This makes continuous delivery possible.

You should have at least three Continuous Delivery Environments
Dev environment, only used by dev team
Customer test

Do not add security patches to your live servers.  Instead spin up new server, add security patches, install your software and deploy.

Puts lots of disk space in build servers so you can keep old builds for testing and redeployment.

Use SpecFlow to automate Gherkin language tests ("When I log in","When I am on the site")

PhantomJS is a headless browser that can be used so IE doesn't pop up all the time.