CI / CD Build Tooling for Sitecore

Being a sell sword, I can comment on a lot of different stacks (along with providing my preferred). Following on from a discussion Sitecore Community – CI / CD I thought I would share my thoughts a little on this subject:

Fundamentally most Continuous Integration / Delivery environments involve the following elements (in a very rough ordering): Source Control > Build Tool > Automated Testing Tools > Code Metrics Tool(s) > Deployment Tool(s) > Sitecore Content Deployment Tools > Environment Scaffolding > Monitoring

Before I go any further, I think I should state what I believe to be the MOST important goals of your CI build environment.

  • The simplest to manage / manipulate. The tooling should get out of you way and soak close to zero time.
  • Should be maintainable by the majority of the development team, not ‘key holders’.
  • Deployments should be done by non-developers.
  • It just works – once set up, you shouldn’t have to tinker with it.

My biggest bug bear of any system is where only the Solution Architects / Team Leads can manage the build process. QA’s testers / product owners should be responsible for sending stuff to QA / Production (if there is to be ANY human involvement at all).

So hear it is split down by element:

Source Control

Source control tools are a way of maintaining your codebase state.

What I look for in the tool: Ease of management, doesn’t impact the regular development process. Note – I don’t like server side branches much, so I wouldn’t normally factor that in to a team I ran, however, any git implementation. If Git – SSH support is quite key since it prevents the need to have to plug user credentials into your build tooling, and helps get around a weakness in JGit (library used by TeamCity amongst others) regarding collisions with HTTPS connectivity.

Worked With: TF Version Control, TFS GIT, GitHub, GitLab, Bitbucket ( / Stash), SVN, PVCS, SourceSafe.

First Choice(s): Firstly, it is any of the pure Git tools – Github, GitLab, Bitbucket.

TF Git has only just gained SSH support in 2015(?) and is a tool that is retro bolted on to a suite (SSH support is a MUST to me). It also tries to force in TFS concepts (for codereview and the like) which I believe is wrong.

Compared with GitLab, Bitbucket and Github, I think that shows. The PR process I think has a better UI in both Bitbucket and Githubs offerings (though I haven’t seen GitLab for a while). I believe GitLab used to be the cheapest for a self hosted solution.

If I had to choose one, I would probably stick with Atlassian (purely UI familiarity), but certainly wouldn’t cry if the another pure git solution was chosen.

Last Choice(s): TF Version Control and SVN are miles behind their competitors in this regard. TFS over all prompted this post SVN – I don’t actually mind it as a tool so long as you accept its limitations in terms of successful branching. I would simply run the whole team off trunk / master. PVCS and Sourcesafe are kinda defunct so I wouldn’t consider them for any new projects.

Build Tool

The build tool allows you to compile your code and package it into a format to be picked up by your deployment tool.

What I look for in the tool: Ease of management, ability to set up new builds quickly.

Worked With: TeamCity, Jenkins, Bamboo, AppVeyor, TFS

First Choice(s): TeamCity / AppVeyor. Some of this is familiarity with TeamCity. TeamCity has a super friendly interface, builds just about anything, links to just about anything and has convenient code coverage metrics. It also has good support for MS based stuff – powershell and the like.

AppVeyor doesn’t work so well if you have dependencies that are not in your repo (think open source where you cannot commit the Sitecore binaries), but if you don’t its a beautiful thing!.

It’s worth noting that Jenkins I would happily use, but it’s interface for me is a bit more ‘Java’. I believe it still has a bit of a reliance on ANT scripts which can be daunting to some.

Last Choice(s): TFS by a mile. It is incredibly inflexible in terms of build and has been BY FAR the longest to set up. TFS also (in most environments) has become a ‘key owner’ solution – i.e only the tech leads / architects have any access to modify templates. This tends to end up being a blocker for the team. TFS also tends to be the only tool which dictates how you structure your codebase. This for me is a flat NO. The tool should work around you!!.

Automated Testing Tools – Unit Testing

Unit Tests are critical in achieving CD nirvana. If you cannot ensure your code behaviour is correct between iterations, you are going to struggle to not break things as stuff gets committed by your developers.

Worked with: nUnit, xUnit, MSTest

First Choice(s): nUnit / xUnit – only due to familiarity and ease of integration

Automated Testing Tools – Other

Automated testing of functionality are also critical in achieving CD nirvana. If you cannot ensure your functional behaviour is correct between iterations, you are going to struggle to not break things as stuff gets committed by your developers.

Worked with: none 😦 😦

Code Quality Metrics Tools

Code Quality metrics tools help to ensure that your codebase is in reasonable health.

What I look for in the tool: Ease of management, interfacing well with the build tool.

Worked With: SonarQube

First Choice(s): The choice is obvious here (but only because its free and most clients are tight to pay money on this). For me, it should be integral to your build solution. Would love to try more when time / budget allows.

Deployment Tool

Deployment Tools allow you actually deploy the compiled code from your build tool in a standardized manner.

What I look for in the tool: Ease of management, interfacing well with the build tool.

Worked With: Octopus Deploy, Redgate Deployment Manager, Pure Build Tools (+ Scripts), Microsofts Release Manager

What I look for in the tool: Ease of management, interfacing well with the build environment, little reliance on scripts.

First choice(s): For me – Octopus Deploy wins out here by a country mile. My biggest fundamental requirement from a deployment tool is it can be operated by non-developers. In a perfect CD world, we would go straight to Prod, many development houses won’t even go straight to QA. In this regard, the promotion of code should NEVER be the job of a developer. Octopus in my opinion facilitates this better than any other tool that I have used.

Last choice(s): I think it has changed somewhat, but at the time, Release Management was heavily integrated and driven by Visual Studio. The web interface was sub par at best and it required a lot of scripting to work well.

Redgate deployment manager was similar to octopus (they were forked from the same beginnings) but I think has now been discontinued.

Scripting from a build tool (for me) is just the wrong approach. It forces your users into the build tool (which if TFS, kinda mandates Visual Studio). Scripting for me in this process is there to fill in the gaps where the tooling doesn’t quite achieve your solution out of the box not to RELY on them.

Sitecore Content Deployment Tool

Sitecore Content Deployment Tools are responsible for deploying content to the sitecore environment

Worked With: Unicorn, TDS, Tree Serialization, Manual Packaging

First Choice(s): I happily work with Unicorn or Hedgehog’s Team Development for Sitecore (TDS). They both approach my issues in a similar manner. I personally don’t like or use many of the extended features of TDS (file deployment and the like). For me – TDS is more configurable in many areas & the less hardline approach can be handy. I like its packaging features too.

I do however like the speed of unicorn’s sync operations, and the simplicity to deploy content elsewhere.

Last Choice(s): Tree serialization is the out of the box solution for Sitecore. It is just not that good for deployment purposes. Manual packaging is great if your developers are structured, but things almost always get forgotten.

Environment Scaffolding

Environment scaffolding tools ensure that you can deploy to and upscale your environment quickly by provisioning machines ready for deployment.

Worked With:, Azure Powershell

Others to look into: Puppet / Chef

First Choice(s): Both work well for provisioning environments. allows this across more endpoints (including azure), so I would probably lean toward this

Last Choice(s): Direct Azure integration (only because its tied to tech)


Monitoring tools are necessary to ensure your deployments haven’t screwed things up

Worked With: New Relic, Cactii

First Choice(s): Monitoring is all about early warning, most tools allow this – including the one above.

What is my preferred stack and why?
Any Pure Git Tool > TeamCity > SonarQube > Nuget > Octopus Deploy > Unicorn / TDS

Why?: For many codebases, I could comfortably install TeamCity and set up a CI build + Deployment in Octopus with NO reference scripts / hacks / anything else in sub 30 minutes (probably too with AppVeyor). I am sure that you cannot do that in TFS! It gets out of my way, it is simple enough to manage for an average mid – senior level developer, does not require visual studio.

What do I think it lacks compared to the competitors?: Some might argue that it being a multitude of tools is a bad thing – I personally prefer to use best of breed for each and have it disposable if a better solution arrives. Most MS houses I have been to almost completely buy into the ‘Single Tool’ goal of TFS, but I genuinely think its the worst modern tool at the job.

What is my least favoured stack and why?
TF Version Control > TFS Build > Scripts > Tree Serialization

Much of my aversion to TFS is shown in here: Why TFS is probably the worst choice for Sitecore

Why?: TF Version Control is a nightmare – requires VS integration (or slightly better – TFS Power Tools), gets in the way, is slow, clumsy, requires incredible server resources to achieve a fraction of what pure Git tools do on a fraction of the cost and hardware.

TFS Build mandates structuring your codebase in a way it can understand. If you want to build a decent component based architecture, you will find yourself compromised in many areas.

Scripts wouldn’t be considered a sensible plan in many areas of development, for me this includes deployment / management.

TFS also tends to force organizations into using TFS Project Management tools – they just aren’t as good to me as Jira / Ontime / Basecamp and the many other tools in that space.

Tree serialization is the out of the box Sitecore solution, but the other tools just murder it :D.


There is no right / wrong answer to this (well there kinda isn’t). Developers will choose tooling based upon their own criteria. For me though… Don’t use TFS and you’re probably going to have a happier developer life 😀

9 thoughts on “CI / CD Build Tooling for Sitecore

  1. I’m currently looking at CI/CD for a new Sitecore rollout and posts like yours and the one from the forum are very helpful. Thank you for the time you spent in thinking this through and writing it up!

    One thing I wanted to mention is that it might be worth differentiating wording like TF/TFS from VSTS (i.e. Visual Studio Online) and TFS (TFS on-premises). As with pretty much all cloud services, it’s important to be mindful of the feature set that existed at the point of time that we last used (and read or wrote) about them. I would consider TFS to be essentially dead technology that only organisations with on-premises requirements should consider. VSTS is very different. You can see this from MS’ feature timeline, where months worth of existing and upcoming features are non-existent in the current on-prem release:

    MS appear to be aware of the deficiencies in their offerings and are putting a lot of work into resolving it, e.g. the pull request UI you mentioned has just been updated: . It’s also worth noting that they have done a lot of work on git support in the Visual Studio 2015 release that wasn’t covered in your linked “Why TFS is the probably the worst choice for Sitecore” post.

    It probably sounds like i’m just plugging MS here but the truth is that I simply don’t know the best approach! However I am required to do a proof of concept, so to some extent I will find out. I hope (while perhaps you may not wish it!) that you get a chance to look at the full VSTS toolset again as it currently stands, as I’d be very interested to know your thoughts.

  2. Thanks so much for your reply. When I wrote the original TFS post, Git functionality was quite junior in TFS and there was in the organisations I had been working with – a reluctance to adopt.

    Interestingly, unlike you, I consider Tfs online to be little more than regular Tfs with a more rapid release cycle. I have seen NO blue chip / medium sized corporate clients who use it. Most of them insist on on premise installations to aid with data protection issues.

    I also in my experience with TFS online found it a royal pain to integrate with other tools – such as teamcity due to the single sign on that it insists on using.

  3. I feel heavily frustrated by TDS so I want to object to it beeing called a “first choice”.

    TDS is probably fine if used just for CD, but as soon as you have a team that wants to work together it starts to get a pain in the ass. The scproj file gives ugly merge conflicts when two branches contain different item adds/deletes, which are unneccessary as the file structure contains all the information needed. The .item file format is a pain with version control, hedgehog tried to rescue it some with their custom merge tool which helps only little, so it’s still is a fair amount of pain – it doesn’t help with link lists or if you use stash or [some other merge tool] for merging. Unicorn just doesn’t have these issues as it has no “index file” and the file format allows for much easier merging.

    • I understand your frustrations and some similar ones myself on earlier projects. I found it a lot less so when I started to structure my tds projects to match my components (thus smaller structures, less chance for merge conflict and long sync times). Unicorn also has some issues when used in anger, and its delivery mechanism for CI is not as slick in my opinion. I will stand by my choice of either or 😀

  4. Hi Nat,

    Great post! really appreciate your effort to share this knowledge!

    We are currently using a stack that is almost in line with what you favor in terms of tools:

    We are using GiT for source control.
    Teamcity Listens for Commits on a Develop Branch.
    Octopus Deploy has Base Sitecore install already uploaded and deploys compiled code package on top of it via NuGet Packages to Test server.
    CD and CM server running SQL server DBs
    Unicron will Sync serialized content once deployment is done.

    However there is one hurdle I am currently trying to tackle is that the base Sitecore install does not include the DBs and we are still having to manually drop those on the Db server and attach them via SQL mgmt Studio . . > Our System admin uses pupper to provision these boxes. seeing that you actually mentioned this tool any idea how we can automate this step at scaffolding time or even at deployment time?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s