As a consultant in the CMS industry for nearly 10 years, I work on and install software on my customers’ infrastructure in Development, Test, Acceptance or Production (DTAP) environments. However, as an integrator/developer, I (like most developers) like to do my software development in an environment that I have complete control of. Having to ask an administrator if I can reboot a machine, install Visual Studio (or other desktop products) on their managed servers, or to call a DBA to backup/restore a database just slows down the development cycle.

Developing for the SDL Tridion CMS

In my time working at SDL Tridion, most consultants had at least one VMware image which contained  a Windows OS, SQL Server, Visual Studio, DreamWeaver, XMLSpy and of course the SDL Tridion Product Suite. Essentially, they had a slimmed down version of a customer development environment running on their laptop. This is great when working on the weekend, or on a train or a plane. Of course, a license had to be purchased for all non-Tridion software for each VMware image, but as an SDL employee, you received an internal license for all SDL Tridion software which you could use at any customer. This was a great situation, as we all had common code-sets that we could port between customers, who in turn benefit from the knowledge pool within the SDL Tridion Professional Services group.

I also spent some time working at an SDL Tridion Partner in the Netherlands, where we worked with much the same VMware approach. The only difference was that we used a partner license key for the Tridion products. I would happily build solutions on my VM image, and then when I had done my testing, I would port the code to the customer’s development environment, where we would integrate it with the existing code base before moving it through the various test and acceptance environments before eventually deploying the code to the production servers. Effectively this meant there were five standalone environments:

  • Unit-Development (installed in a VM on each developer's laptop)
  • Development (installed at the customer, and used to integrate code)
  • Test (installed at the customer, used to create a new deployment)
  • Acceptance (installed at the customer, used to test a new deployment process)
  • Production (installed at the customer, used for editing and publishing customer content)

This is commonly called the DTAP street by Tridion people (or OTAP in their Amsterdam office), with the first step clearly missing. Should we be talking about a UDTAP street? The point is really moot, because customers buy licenses for their environments, and don’t care that SDL Tridion consultants have extra environments which speed up their implementations and save them money in the long run.

So far two thumbs up, but...

Today I am an independent contractor, and spend a lot of my time advising SDL Tridion customers and partners how to set up a Tridion development team and how best to structure their software development and release cycles. So I started out trying to explain the way that I have always done it, and the methodology behind the process, and that’s where I ran into a number of hurdles.

Hurdle #1: Customers don’t often buy licenses for four environments (let alone five). I will cover more on the DTAP theory in another blog, but until then, let’s just say that most customers think that Dev/Test/Prod is enough (perhaps it is a way to meet budget requirements), and consider their staging environment to be a QA (or Acceptance) environment.

This presents a major challenge in ensuring quality releases, and when I explain why four complete environments are important, most customers with a structured policy on code deployment go back to their sales rep and get licenses for the fourth environment.

Hurdle #2: Having explained the five-environment model to several SDL Tridion partners with off-site or off-shore teams, they particularly like the approach, as most of their developers are located a long way from their customers, and even with current bandwidth availability, the restrictions on available VPN connections to many customer environments makes working directly on the customer’s own development environment an impracticality (especially when there are multiple developers on the same project).

Unfortunately, the elusive fifth environment is only readily available to SDL Tridion Professional Services’ own consultants. Having read the small print of the partner license for SDL Tridion, it seems that it contains wording which says something like “may not be used for development on customer projects”. Essentially, the license is for internal research, demos and training, and cannot be used as the Unit-Development environment that I had hoped for.

Hurdle #3: As an independent contractor there is no obvious way to get an SDL Tridion license for research purposes (let alone to use as a standalone development environment). I have access to several partner licenses (as I work for several partners), but I have to maintain these in very separate VMs, and only use them when researching work for that specific partner (which raises an interesting question, if I do some research, and then someone uses my sample code in production, did it just become development work and technically a license violation?). This makes work very slow and tedious, especially when working on several projects in one day.

As a person who doesn't like hurdling very much, I have been looking for ways to level the playing field, and make it easier for independent consultants (and partners) to enter the SDL Tridion consulting space (which so desperately needs more qualified talent).  Microsoft has a number of programs designed for just this. There is DreamSpark for students and BizSpark for small new businesses. My company, UrbanCherry, is a BizSpark member, and it gives us a full MSDN license to all of their software for development purposes for three years. Combined with a decent laptop, VMWare Workstation ($190), Dreamweaver ($200), and XMLSpy ($500), we have everything we need to create a standalone SDL Tridion development environment, except SDL Tridion 2009 (which is probably more money than a consultant could make in a year).

SDL Tridion Developer Edition

So why not make an SDL Tridion 2009 Developer Edition? I know it has been discussed over and over again, but for some reason it doesn’t exist. Potentially this could be an extra revenue stream for SDL. This got me thinking about what would make the developer edition different from the full blown product. How could SDL Tridion prevent customers from using the developer edition in their production environments, and what would its value be to a developer, to a partner and to SDL?

What would be acceptable "SDL Tridion - Developer Edition" be?

In my mind, the developer edition would need to be the full SDL Tridion product suite with the following limitations being acceptable:

  • Only 1 User (with administrator rights), ideally 2 or 3 so workflow and security could be tested
  • Only support local file system publishing
  • Content Manager (CM) and Content Delivery(CD) only accessible on http://localhost/
  • Only support 2 CPUs on the CD and CM environments
  • No customer support access included (possible per incident fees), most tickets would be supported under a paying customer account
  • All licenses valid for a single server name (ideally separate for CM and CD so that Unix based machines could be tested on the CD side)

What would it be worth?

Well that of course is the real question. We have about $1000 in software for a typical development environment, (remember that we get SQL Server, Windows OS etc free from BizSpark which keeps it low), so spending much more than another $1000 does not make that much sense. So I would put the value somewhere between $500 (XmlSpy) and $1200 (Visual Studio with MSDN). What would it be worth to you?