My Tridion VM bootstrap project

As part of my luxurious and privileged seat in Tridion Product Management I get to test new stuff all the time. It's great to just point my browser to the build server and download the latest nightly build (stable or unstable) and start playing around with it - how's the notification area behaving? Can I assign tasks now? How's the workflow engine doing? etc.

While this is great, it has a certain, heavy, repetitiveness to it. Every time I get a new build I need to either completely uninstall Tridion and start again (we obviously don't bother doing migration scripts between minor builds) or start from a completely new VM.

And this means:

• Create new blueprint
• Create new schemas
• Create new content
• Create new publication target(s)
• Configure Content Delivery for HTTP Upload
• Configure Website
• Configure Session Preview/Experience Manager

Even the most adept Tridion professional will recognize that this takes a LONG time to set up, and all to be destroyed soon, since a new build comes in tomorrow.

So I started, slowly, creating a series of C# command prompt programs to automate stuff for me. Initially these scripts would just create my diamond-shaped blueprint, a set of schemas, and some components. Then, I added a script to import content via RSS so I get some real content in it. Then, I expanded it to also create pages for these components. Then I added configuring the Publication Targets and Target Types. Then I added expanding the Tridion pre-build web applications and copying the configuration for these. Then I added actually creating the sites in IIS. Then I added support for all this to be configured via a XML file. Then I added changing the default templates to include Experience Manager building blocks. And finally I added support for Tridion 2011 too.


And now I decided to share it with everyone. The two projects I use to prepare my environments are available under MIT license on Google code.

There are 2 projects in here: CreateAnEnvironmentForMe and ImportContentFromRss. Each does what its name implies, and there's reasons why they are separate which I won't care to elaborate. I also offer no support whatsoever and really just hope the community can help evolve this solution to something a bit more stable. This code is not intended to be used in Production Environments, and there's no guarantees it will work for you.

These tools are tools I use, and they're fit for me to use them. If you need more rounded corners to use it, please feel free to change it - contact me via this forum or the google project if you want committer rights on the project. I typically run these projects from within Visual Studio, because I expect them to fail here and there, and this allows me to quickly fix them.

Hope this project can help others out there.

Whatever the future may bring... will be outdated soon

Had an interesting request from a customer recently:

Ensure that the product will continue to support different form-factors and whatever the future may bring.

How can I answer that with anything else than a very bold "Of course!"?

Whatever the future may bring has been pretty much my domain lately. I knew that moving from Professional Services to Product Management would bring a rather large set of changes. For instance, I can't really complain about feature X not being in the product, since it is my job to decide what goes in the product. Another interesting change is that now everyone thinks I need their advice :)

Anyway, the future proofing of anything we do is not a small challenge, and it applies to everything we do today. For instance, my LinkedIn profile stated:

With 10+ years of experience, of which 8+ as a consultant

Though it might sound interesting, it had been written in 2004, making it quite out-of-date for something that contains numbers (I updated it now), which in turn made me rewrite my SDLTridionWorld profile to let you do the math instead.

So here we are, trying to decide how to future-proof a product, and we can't even write text that won't be obsolete next year. I was privileged to have seen Mike Walsh present at Innovate last year, and one slide that made an impression on me was this one. Yes it does, unfortunately it's a one-way communication channel.

So, how do I prepare for "whatever the future may bring"?

I guess this is one of the advantages of having a relatively light foot-print in our content delivery stack. You want 2001-style XML flat file publishing? You got it. 1999 style JSP with embedded code? You got it. Even (God almighty protect us all) VBScript ASP pages? You got it. What about MVC? You got that too. What about Service-based? Yup, got it (with OData no less).

So, what's next?

I have my own ideas about what's next, and we're working hard to 1) validate those ideas and 2) build it into the product, but can't share that just yet (another one of those things that change with being in Product Management - don't talk about what you can't commit to). Keeping in line with what we built up to today, it will be something that you can extend the hell out of, and will have lots of functionality you will not discover until 3 years later... (WAI anyone?) And maybe, just maybe, we can finally drop Classic ASP support ;-)