continuous-integration

Building high quality end to end acceptance tests suites is hard, and creating API stubs (aka mock servers) can be surprisingly time consuming. WireMock.net can help speed this up. E2E testing is hard End to end testing is hard for many reasons, but I think one of the most common is that the developers under estimate how much time to allow for it and then rush the job. Most E2E test harnesess I have worked on, (including several I wrote myself!...

The npm install step in my Teamcity CI build for an angular app I have been working has been failing intermittently and I finally uncovered the reason. TL/DR The combination of McAfee Anti-virus and network mounted user AppData folders was the culprit - moving them to an unscanned local folder fixed it. npm install was failing the build intermittently when run by our build software Teamcity on a windows agent with ugly errors like:...

Stumbled on a little gotcha today when using nuget packages as deployment artifacts to be send to Octopus Deploy and thought it worth documenting so i don’t forget next time. The quick answer is that you cannot push the same package and version to the built in octopus deploy package repository - if you try you get 400 (Bad Request). Our build process goes a little like this: Install the Octopack nuget package in each deployable project in the solution Compile the solution using Teamcity and msbuild, specifying the octopack build property to output packages msbuild MySolution....

In VS 2013+ msbuild moved out of the core .net framework and is available as a separate install for build agents know as “Build tools”. You need to be aware that MsBuild has moved path for studio 2013 and 2015 - the path of msbuild in 2015 is C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe (moved from C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe in 2013 and C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe in 2012 and before). More info on the studio blog from 2013....

In addition to my previous post about how to do better code reviews below is a list of specific things to watch out for during code reviews, in no particular order: All the CI builds are green The diff/pull request should be small enough that it is reasonable to review it in under 30min - avoid giant whitespace changes. The entire app build is scripted and available with one click/script CI builds are clearly named and well organised, with separate build/test, deploy and acceptance tests stages Deployment is 100% automated New code does not introduce unnecessary duplication....

You have a substantial development project with several people working on it and you expect to be around for a while. Having your source built by Teamcity/TFS/Jenkins etc is a good start, but there is plenty more you should probably be doing. To help out, here is my checklist of a good quality continuous integration/continuous delivery pipeline. It takes a while and some experience to set it all up but the long term benefits to developer productivity are well worth it....