CX & Design November 03, 2014
DD4T: The vision for collaboration
Recently I helped move DD4T onto GitHub. There wasn’t much wrong with Google Code but I really think it is lagged behind in support for Pull Requests which are a key feature in proper open source collaboration as we’ll see.
I have a vision for how people will collaborate on DD4T more like a standard open source project and I hope to explain what this is in this blog post.
So, the collaboration model in DD4T in the past has been a traditional model with SVN. Due to SVN being a centralised Source Control solution, participating in DD4T involved anyone being a committer.
This means a lot of code goes into trunk and isn’t always tested properly. Branching can mitigate some of this but we all know SVN can get messy with branches if the process isn’t tightly controlled.
How do we solve this?
Switching to Git allows for a workflow called the Forking Workflow. Atlassian do a good job of describing the workflow, but I’ll have a go at summarising anyway.
A forking workflow relies on using a decentralised source control provider like Git. Each contributor has thier own copy of the repository and makes updates. When they have an update that they want to share, they can create a pull request back to the central repository. They can also keep their version up to date from any other merged code.
The project maintainers (Quirijn et al) will review the pull requests and merge in the ones that are useful.
We’ve created a new repository at Dept which Chris Eccles has been using to submit code back to the DD4T core via pull requests. A few others have already submitted Pull Requests to the new repository, so get involved!
There were a lot of ideas discussed in the last DD4T board meeting which we need help with.
We’re hoping to get:
CONTINUOUS INTEGRATION & TESTING
At Dept we rely on Continuous Integration to ensure our code is compiled, tested and deployed regularly and consistently and the DD4T team would like to see the same benefits. We’ve been looking at setting up a Continuous Integration server to compile and build the product. Chris Morgan is helping me out with this at the moment.
The idea is be to build into a version of the Tridion Reference Implementation and run some automated smoke tests to give us an idea of whether pull requests have caused any serious issues.
The excellent DD4T wiki is looking a little out of date and unloved on Google code. We’re looking to get that migrated and onto Github soon.
It’s coming and it’s going to be awesome. Here’s some of the features for the .NET release. Of course a Java release will also come soon.
- Potential JSON data format
- REST based access to the Broker DB
- Strongly typed models
- Component Presentation support in dynamic queries.
- Smart Target support
- Bug fixes
For more detail, see the roadmap presentation of the Benelux usergroup by Quirijn.
I hope I’ve given you an idea of what the DD4T team is up to and how to get involved. Join the DD4T Google group if you want to ask anything.