CX & Design November 10, 2014
DD4T: Continuous Integration
Off the back of Rob’s post on the vision for collaboration within the DD4T framework, I thought I would write about progress on one of the key aspects – continuous integration (CI). Now that the DD4T project is hosted on GitHub and has a much smoother collaboration workflow with forking and pull requests, it is more important than ever to automate the integration process.
The ultimate goal for continuous integration within the DD4T framework is to accept community contributions and framework enhancements confidently, ensuring the framework remains stable (and even backward compatible).
Before I could begin on the actual continuous integration road, I needed to select some tools for the job. I did not get a chance to collaborate with the other DD4T contributors (other than fellow BB’er, Rob), so this may change over time, but here is the technology selected for the first attempt.
As a base for the integration server, we began using a cloud-hosted SDL Tridion 2013 SP1 image with the current release of the Tridion Reference Implementation (thanks to Will and Bart).
It gave us a preconfigured environment, complete with a working website (based on DD4T), ready for testing the framework builds.
Often (more normally) the build server will not be hosted on the same logical machine as the delivery environment. However, in the interest of cost and speed, this is a single server environment.
Continuous Integration Platform
The CI tool of choice for the first attempt is TeamCity because:
It’s easy to set up, use, and configure
It’s widely-used and well documented
It has strong integration with a wide variety of tools and technologies
The Professional server version is free for up to 20 build configurations and three build agents
I’m familiar with it, as we use it at Dept.
The Continuous Integration Process
Once the tools and host had been chosen, it was time to configure the build within TeamCity.
At the moment, the build is quite basic (and only .NET), but over time I hope to improve it with a little help from the aforementioned Rob!
The initial build process is outlined in the image below and is setup to build the master branch, all active branches, and all pull requests.
With the build trigger setup to watch the DD4T GitHub source control repository, the action comes thick and fast. Below are the build results for the master branch and the existing 6 pull requests (all 19 branches are “Stale”).
Before moving on, it is important to reflect on these results for a moment…
From this screenshot, everything looks great; only one build failed, with a simple-to-fix namespace issue. However, that is over-simplifying the situation. Although we have a unit test build step in the CI process, we don’t have any unit tests to run. In the current configuration, a successful compile equals a good build. Going forward, this is obviously not a sufficient check before incorporating changes into the framework.
As a nice little bonus, I’ve also installed a cool TeamCity plugin, which updates GitHub pull requests with the status of their build attempt. This will allow contributors and moderators to quickly check on pull requests and speed up their acceptance into the framework.
This image shows a pull request that, when merged with the master branch, built and passed all tests successfully, which you can see here.
This image shows a pull request that, when merged with the master branch, either failed to build or did not pass the automated testing steps, which you can see here: https://github.com/dd4t/dynamic-delivery-4-tridion/pull/2
Now that the project is building, we need to work on improving on a few things.
Firstly, a continuous integration process is only as good as the automated (and manual) tests that can be performed following a build. Therefore, a priority will be to improve the automated testing within the framework. To make sure that updates and pull requests to the framework work, we need to add a full suite of automated tests, ensuring that the addition really works!
Once we have a more robust test suite, and can better guarantee that a build is truly ‘successful’, we can continue to improve the build process itself. One of those improvements could be working towards automating the creation of a test website (running the current build of DD4T) for the contributor to easily smoke test manually.
Finally, as we get more advanced, we could add automated acceptance tests with a framework like Cucumber, but that is a discussion for another day.
This is the first step on a long road, but I am excited to make progress and refine my CI skills to boot.