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 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 https://cardinalcore.co.uk/2015/07/15/why-tfs-is-the-probably-the-worst-choice-for-sitecore/. 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.
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 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 tools ensure that you can deploy to and upscale your environment quickly by provisioning machines ready for deployment.
Worked With: Packer.io, Azure Powershell
Others to look into: Puppet / Chef
First Choice(s): Both work well for provisioning environments. Packer.io 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 😀