About five years ago I wrote a blog entitled the “The Fifth SDL Tridion Environment” in which I explored the need for additional development environments. SDL solved my frustration in part, by creating the MVP program, which carries the great benefit of a special MVP license for Tridion. The license can be used for personal research etc., but not on customer or partner projects. So fast forwarding to 2014, independent Tridion developers are in much the same boat of needing to use a customer’s license installed on a customer’s server.

A lot has changed since 2009, and I am now on a project where we have a globally distributed army of developers (many of which have no knowledge of Tridion or any other CMS) working on a Tridion project from their own machines without the need to buy additional licenses or provide training to each developer. SDL may not like this idea (sorry SDL), but the approach I am about to share has drastically increased the productivity of our team, and has removed many of the ‘barriers to entry’ that so many of SDL’s customers and prospects have complained about in the past. I really believe that this is a model that could significantly increase the acceptance of Tridion to the broader developer community.

Developments since 2009

I say “a lot has changed”, and that is true, but there are two key developments which have helped our project get to the development approach we have today. The first is the creation of the OData web service (I think OData was available in 2009, but only as part of a Java stack) which exposes content on the Content Delivery (CD) side without the need for any Tridion APIs in a web application, and the second is the open source framework called DD4T.

The reason that DD4T is so ‘key’, is that it has shifted the lion’s share of development to the CD side. Simply put, there is no need to write templates and debug them on the Content Management (CM) server anymore. Of course we still need access to the CM machine to test out Event Systems, Workflow and Custom Resolvers etc., but the bulk of our work moves to the CD side. OData is the other half of the puzzle, as it gives us a way to build web applications which consume Tridion content without using SDL’s own API. All we have done for our project is provide the glue which brings these two components together in the form of a DD4T Provider which uses OData to retrieve content from the Broker Database rather than the traditional mechanism that uses licensed DLLs or JAR files embedded in the web application.

So what does our new development process look like?

Essentially we have a GIT repository which contains a .NET based DD4T web application and the new OData Provider. On the client development servers we have SDL Tridion 2013 SP1 CM and CD components installed, including the OData Service and XPM. Each developer can check-out the web application from GIT, and start it up in Visual Studio, and tweak and change anything they want. The only pointers to SDL Tridion are the URLs of the Content.svc and Linking.svc OData endpoints on the client’s CD server which are stored in the web.config file of the web app.

Traditional SDL Tridion Template Developers

Tridion Template Developers install the standard DD4T templates on the CM server. In our case we have 300 existing publications with over half a million pages of content. The templates for these pages were migrated to use the new DD4T templates using a simple Core Service script, and all of the pages were published to the new Broker Database where they can be accessed using OData.

DD4T/MCV/.NET Developers

DD4T Developers are responsible for creating Page Views, View Models (for Components), Builders, and what we call Stub Views. These Stub Views are very simple views which exposes all of the fields of the ViewModel (with the XPM markup), but with no HTML.

CSS, JS and HTML Developers

HTML developers are responsible for the turning the Stub Views into working HTML once the stubs are delivered (i.e. once the MVC developers have pushed them to GIT). They can work locally on their machines without getting in the way of any other development.

JS and CSS Developers work in much the same way. They can build new CSS and JS locally, and test it with all of the existing content. Gone are the days of them testing with Lorem Ipsum samples, they can now see every whacky scenario our editors have come up with over the years.

The result is parallel development streams for MVC.NET, HTML, JS, CSS and Traditional Tridion CM development. There is little or no bottle neck created on the Tridion Developers, and the front end developers can see their changes using real content.

We still have traditional builds which move the application through the DTAP environments. What differs is that we can now test new releases of design or functionality with live production data by pointing our local repositories at the live OData endpoint. This makes fixing any bugs that have snuck through the DTAP process very easy to replicate, resulting in much quicker fixes.

Conclusion

This feels like a pretty perfect scenario to me, but there are of course some downsides to this solutions. The primary one being the OData Provider. To be blunt, it is far from optimized, and it performs like a dog when starting up, and I would never run a production server on this code. That is not to say that this solution is unusable, we simply swap out the OData Provider for the SDL Tridion 2013 SP1 Provider, and drop in the ‘config’ folder, SDL Tridion DLLs/Licenses into the ‘bin’ folder when we do a build to DTAP servers, and hey presto, we have a high performing MVC application using SDL’s official approach for accessing content from the Broker using their APIs.

The only other downside I have found, is that I can’t test Experience Manager on our local instances without doing a little host file magic to resolve the localhost name.

I am working on a stable release of the OData Provider, and hope to get it onto GitHub in the coming weeks, but if you want to play with it before then you can download it from http://www.urbancherry.net/downloads/.

Let me know what you think of the approach, and let SDL know if you think such an approach would be beneficial to you and your team. It has certainly helped us speed up development, utilize lower cost resources for front-end development, and free up our Tridion Developers to work on more complex features.