Application Life Cycle Management for SDL Tridion Projects

In this Article I would like to share what I think is a workable and efficient Application Life Cycle Management for SDL Tridion Projects. We need to consider the different project stages and SDL Tridion dependencies before we define the Strategy to maximize the ALM (Application Life Cycle Management) effectiveness.

Please note that this post is based on Agile projects (implementations) and assuming a mature ALM level during the implementation as well as all of the recommendations are my own opinion and cannot be considered SDL guidelines for Agile projects.

Blueprint and Schemas are not Agile

One common error during Agile implementation is to think that the Blueprint and Schemas can be partially defined and finished, curated and tuned during the different steps (sprints) in the project. Consider the Blueprint and Schemas as your model and infrastructure (when an Civil Engineer designs a House, he delivers a completed blueprint for the house that contains electrical, plumbing and other multiple aspects for the home, then it can be built in different steps (sprints)). Consider the Blueprint and Schemas as the base of your project, I know it will sound archaic but I would suggest an small waterfall to completely define the Blueprint and Schemas (I know that we cannot completely define the Blueprint and Schemas in one single shot, but we have to do our best and be creative in order to consider all the possible scenarios and make them as extensible as possible, you can check the Miguel Migulez blog for Blueprint and Schemas best practices)

click to see original image

Determine a Dev Environment and Process

A typical SDL Tridion Dev Environment for Agile projects must be connected to a Code Repository (Git, SVN, …) as well as a tool for Tasks and Defects management (TFS, JIRA, …) as well as an Deploy Automation tool (Teamcity, Jenkins, …). The following diagram shows how a typical Dev Environment is set up.

click to see original image

In the diagram below we can notice the following elements

Dev Branch

In order to separate the code base it is mandatory to configure a Branch that is intended only for Development. This Branch will contain the latest code for Template Building Blocks, Event Systems, Workflow as well as the Presentation Server pieces. It is important to separate it from the Master branch that is intended only to contain code that has been properly tested and quality assured

Build Server

In order to improve  productivity it is important to accomplish Continuous Integration so that after some code changes as Pushed into the Dev Branch an automated build is performed in the Dev environment. It will improve developers productivity since it will hide tasks like Upload Template Building Blocks, Deploy Event Systems, Deploy Workflows or Presentation server elements

Version Control

All the different Code Branches are controlled and defined in this element, as well as it support Pull and Push requests in order to apply or retrieve code changes.

Work Tasks

All the different Technical Tasks that represent the different User Stories that represents an Sprint

Unit Testing

This is an optional but high recommended step and should be automated during the Continuous Integration (Fail the Build process if a Unit Test fails)

Dev Deliverable

This is the result after a Push operation is performed, it will contain a package containing (Compiled Template Building Blocks, Event Systems, Workflow, ….,  and Presentation Server elements)

Determine a QA Environment and Process

The QA Environment uses the Master Branch coming from the Version Control system. For QA I would not recommend an automated build process (Continuous Integration) instead I would suggest a time basis build process (Nightly Builds for instance) so that we can deliver an stable and testable version of the different components to be tested by the QA team next day.

click to see original image

In the diagram above we can see the following elements

Scheduled Built Artifact

Final deliverable (Artifact) that is built timely basis (Nightly Build)

Version Control

QA deliverables should be built pulling from the Version Control System (Master Branch)

Determine a Preview and Live Environment

As part of the QA process it is recommended to define a central repository for the different tested version of the deliverables, it is called an Artifactory, We will be manually deploying to Preview and Live (Prod) from the Artifactory.

click to see original image

Gluing everything together

The following diagram shows how the different environmetns defined above are glued together, We are also including Content Porter as an important piece in this strategy. Content Porter is responsible to port Tridion Items that doesn’t live in the Artifactory by in SDL Tridion like (Blueprint, Schemas, Taxonomy, Folders, Structure Groups, ……)

click to see original image