Moving from templating to software development

Tridion, Continuous Integration, Templating, Software Development

The way we're developing SDL Tridion websites is changing. We we're used to templating everything in Tridion and Tridion was our version control system. The web application we published were jsp pages, aspx pages, or pages based on some other technology. We're moving away from this way of working now and we're moving towards Software Development. We're hearing things like MVC, Git, Git Flow, Configuration Management, Dependency Management, etc. What does this all mean for you as a Tridion developer?

MVC

MVC stands for Model View Controller. This is a very popular design pattern which is the main pattern used for web development today. For .NET there is simply MVC and for java there a couple of popular ones like Spring MVC and the Play framework. DD4T has been developed with MVC in mind and has support for .NET MVC and Spring MVC. The DD4T core could also be used in another framework like Play.
MVC provides structure to your application. Models house your data, views your layout and controllers hold your logic.

Version Control

Tridion store versions of your templates, but it is no SVN or Git. With moving to MVC development you can store your code and your code history in a source control management tool. There are a lot of nice environments to choose from, in-house or hosted in the cloud. Git has been the new standard for a while now, so use that. But be careful what you add in there. Not everything needs to go in there.

.NET Guidelines

Do not add the following to your repo's and add those directory or files to your .gitignore file:

  • obj folders are generated by Visual Studio, ignore them;
  • bin folders are generated by Visual Studio, ignore them;
  • packages folder in the root of your solution is generated by NuGet, ignore it and enable nuget package restore (Do add the .nuget folder);
  • .suo files are generated by Visual Studio, ignore them;
  • .user files are generated by Visual Studio, ignore them;

  • if there is a dependency, do not add the dll to your repo, use NuGet or a even a private NuGet repo like Sonatype Nexus (Works with .Net, Java, Grunt, NodeJs, Ruby, etc..;

  • Make sure your project can build from checkout;
  • Use MS Deploy / Web Deploy to create deployment packages (This is a good way to check if all files are committed and nothing is missing as well);
  • Install Web Deploy on your web servers so packages can be deployed easily using a standard deploy method;

Java guidelines

  • Use maven;
  • Do not add jar files to your repo;
  • Deliver war files;
  • Consider automated deployments with Tomcat Manager;
  • ignore the target folder

Stop Templating!

The most important part of this post is the message to stop templating. MVC development has a small portion of templating in it and the structure of MVC allows for a clear seperation of layout and logic. So stop adding functions to the views of your MVC application. It doesn't belong there. Use your models and controllers or even helpers to add that logic to your layouts. Think before you add any code to them. If your if statements are too long or your if statements are repeating in your views, you're doing it wrong.

Configuration Management

Make sure that the package you're creating as a result of your build, can be deployed to all of your environments. So think about your configuration and how to manage enviroment configurations within your package. There are multiple solutions for this (I've written about .NET solutions on this blog).

Dependency Management

Check if your Visual Studio solutions aren't too large. You might need to split them up. If there are dependencies between projects, you might need a dependency management tool like Sonatype Nexus. Just deploy those dependencies on such a system, so that other projects can reap the benefits too and you can make your solutions smaller. This also improves reusability of your code.

Quality Management

If your project is nice and clean and is able to build from checkout, you can run your code on continuous integration tools and then move to continuous and automated deployments. After that tools like SonarQube can automatically detect security issues, measure code coverage, copy / paste behaviour, code complexity, etc..
This will ensure a certain quality standard that we developers want to and should deliver. You are able to ensure your customer that you've delivered the quality that he expects. You are able to that quality using such tools and the reports it generates.

Finally

This is quite a lot to setup. But it will benefit you, your project, your customer and the relationship with your customer in the long run. Speed and accuracy will improve over time. Deployments will take less time, they will go from days to minutes. Really? Yes, really!

If you want to know more about this, please read my blog, or contact me.