We've been using continuous integration for building Tridion C# TBBs for a couple of years and thought we'd share our development workflow and why we're working in this way.
We found that when multiple developers were working on the same Visual Studion C# TBB project they were sometimes overwriting each other’s changes if using the standard post-build action. Building the project automatically uploaded the latest compiled DLL into the Tridion Template Building Block and overwrote previous changes other Developers had uploaded if the copies of each set of code weren't up to date.
For most projects we use Subversion (SVN) for source control to store the source code, however, this didn't help as developers were either spending a lot of time ensuring they each were getting the latest version of the code from SVN, or were uploading the DLL manually at predefined times, when everyone was ready. It made testing of TBBs in the Template Builder difficult and it didn’t fit in with their usual way of working.
We also wanted a way to be able to attach comments on each version of the C# TBB DLL to see what code changes had been made and this wasn't easy (we'd have to cross reference SVN logs with Tridion versions).
We sat down to discuss how we could get the two workflows (source control and automatic upload to Tridion) working together and quickly realised that we were already using the solution for management of daily builds in the development of .NET applications – Continuous Integration (CI).
What is Continuous Integration (CI)?
Continuous Integration is the process of automatically building software at regular times to keep all programmers at the same stage of the development process. It allows teams to test the code base is still compiling even when each developer is working on a different part of the system.
We've been using CruiseControl.NET for CI some time, to get the latest version of our .NET applications from our SVN repository every night, compile and deploy them onto a test servers. Any problems with the checkout or compilation resulted in the build failing, the files not being deployed and an automatic email sent to the developers explaining why the deployment failed (and who was responsible!).
Integration with Tridion C# Template Building Blocks project
We adapted the standard CI process so that a build is triggered only after code is commited into SVN. If the build is successful, then the compiled DLL is uploaded into Tridion using the Tridion Upload executable. We also get the added benefit of being prompted to add a comment to SVN every time we want to commit code/upload a new version of the DLL. This allows the team to communicate what they've worked on.
Note: The example shows SVN and CruiseControl.NET (both Open Source tools), but the process does work with other technologies - open source and commercial.
The full process is:
- The team creates a new C# Modular Templating VS Project and commit to SVN
- CruiseCrontrol.NET is configured for the new project
- All developers work from this SVN solution, however, they can build locally to check their code compiles
- To upload in Tridion and test in the Template Builder they commit their changes in SVN - Any code conflicts with other developer’s work are highlighted and must be merged/deleted before the commit take place
- They are prompted to add comments to the commit – what they have worked on
- CruiseControl.NET monitors activity on the SVN project. When code is commited it automatically gets the latest version, compiles the project and executes the Tridion upload tool.
- If the build fails then an email is sent to the team to inform them of the problem
As an added bonus, SVN works over the HTTPS protocol so it made it very easy for remote developers to integrate into the workflow, and with the VisualSVN plugin for Visual Studio it’s all integrated in into a single application.
I'll run through how to configure a similar set up for integrating Tridion templating with Continuous integration using the tools described above in a later post.