0

I have fair experience on WCM technologies like AEM, Drupal and SharePoint. And am working on Tridion since around last many months. The first thing you expect from any WCM tool is to provide a seamless and quick installation and configuration so that developers can start working on it quickly. In other words Team can focus on solutioning instead of configuring the tool. And hence, this is not even a 2 hours job in WCM like AEM and others. But it looked like a real challenge in Tridion. It took my Tridion experienced friend around 3 weeks just to configure Tridion CM and CD in our local boxes. So, they decided to have just one common CM/CD server and have developers use the same through browser. Now, i doubt if this is the right development environment. I think any WCM tool including Tridion should provide:

  1. Each developer have its own CMS environment to develop and play around
  2. Each code (including tridion things like DWT and all and not only custom code) should be part of a source controller like SVN, GIT (I know Tridion has its own, but its only version control not backing up code)
  3. Developer should be able to merge their changes to a common system (Dev/QA box) seamlessly
  4. It should allow to preview and publish code for tridion (and custom) code.

I know some of the things are already there in Tridion but not all. Also, I have not seen any good document around Tridion development environment best practices/recommendation, which my friend asked for.

I understand that VM is one of the option, but first its not a neat solution, then I didn't find any good sources at SDL site which offers ready made VMs for this - maybe my lack of knowledge.

Do you guys have any thoughts\recommendation on this.

5
  • Welcome to the Tridion StackExchange site. It usually works best when you ask 1 specific question and this allows us to answer it better. I understand you are struggling to get up to speed with Tridion, and the community will help you. However, please share what you have done or are doing, and what you would like to do, and where you get stuck. Then you will help everyone by asking and answering.
    – robrtc
    Jun 12, 2014 at 11:41
  • What exactly is your question? If it is "Do you guys have any thoughts\recommendation on this", the please read the help info as that would be a chatty, open-ended question which diminishes the usefulness of our site, and thus is not wanted here. Jun 12, 2014 at 11:54
  • Hi Bart, thanks for your reply. Apologies for my long and a bit open question. My simple question is whether there is any recommended dev environment for Tridion since I have seen people following one out of multiple approaches - One shared dev server, Tridion installed at each developer workstations, or putting up VM on each developer machines.
    – Vinny
    Jun 12, 2014 at 12:58
  • Hi Rob, thanks for the prompt reply. Looks like I need to be more careful in phrasing question here :). I am working as WCM Architect in Tridion based applications since last one year, but observed that there are multiple and inconsistent approaches being taken for leveraging development environment in Tridion. So, wanted to know the best practice out of all the available approaches from the Tridion experts here. Apologies for the confusion.
    – Vinny
    Jun 12, 2014 at 13:03
  • The documentation describes "typical" and recommended environments, specifically look for the topics on "DTAP" such as this diagram (requires login). Jun 12, 2014 at 16:18

2 Answers 2

3

This kind of query comes up a lot.

Allow me to try to help with some of your questions/issues.


Developer's should have their own environment to develop and play around

This is certainly possible, and is actually quite common. Your restriction would mainly be the license agreement that has been arranged between you (the customer) and SDL. If your license agreement does not include provision of developer licenses, then that's a different problem.

With respect to your Tridion experienced friend, 3 weeks to set up a CM and CD environment is far too long. For example, I created a basic environment last week and it took me around 2 hours.

You state that a VM is not a neat solution, but I would beg to differ. I routinely run Virtual Machines with varying configurations and customer specific customisations. Tridion requires some significant resources to operate, including SQL Server or Oracle, so it's nice to be able to shut all that down as a whole. Running Tridion in a virtual machine does not in any way prevent me from developing templates and extension code locally, which I can compile and deploy to my VMs quickly and easily once I understand the process. Having a VM also means that I can take advantage of snapshots to roll back to previous states of configuration.

Code (including DWT) should be subject to source control

Tridion versioning != code source control. You should, of course, have all of your code (including DWTs if you deem it necessary) version in an SCM system. Tridion does not prevent you from doing so. I think it's fair to say that versioning in Tridion is mainly for content versioning, but it just so happens to work for some other item types.

Developers should be able to merge changes to a common system seamlessly

This is another reason why you should use a source control tool for your code. I have seen customers setting up continuous integration for templating code as well as DWTs, so it is possible.

It should allow to preview and publish code for tridion (and custom) code.

I'm not 100% clear on your question here. There's a great slide in Content Delivery training that I always emphasise when I am giving it... "Tridion does not run your website". Unlike some CMS systems where they both manage and deliver your content, Tridion typically manages content and then publishes it to a data store somewhere (either on disc or into a database, depending on your needs). This means that you can consume this content in 100s of different ways! The Content Manager will show you, via template builder and/or it's preview functionality, what it writes out to your content data store, but it can't show you what your application is then going to do with that output. This doesn't mean that you can't preview though... In my current project, for example, all content is retrieved from a database and processed by a web application. All of the developers can run their code locally and see instantly the results of their changes before committing it to their SCM tool, which then builds and deploys it out to an integration testing server. The editors can use Tridion's Experience Manager interface to edit content in-line on the actual staging web site and then see how those changes will look via the Session Preview feature before actually publishing it.


To summarise, Tridion works differently to many CMS systems that you may be more familiar with. It is very powerful, flexible and it doesn't make too many assumptions about how you want to manage or deliver your content (and code!). Remember though, "with great power comes great responsibility"... Tridion requires you to understand and utilise it's features well to get the best results, but in return it will reward you with an extremely well tailored and customised experience for your organisation.

1
  • Thanks, David for clarifying my doubts point by point. I really appreciate it. You have added one more fan of yours in me :)
    – Vinny
    Jun 12, 2014 at 17:40
3

I understand you would like to know about development lifecycle best practices. First, you could watch the Continuous Integration talk from the Tridion Dev Summit to see how 1 Tridion partner did it. tridiondevelopersummit.com/videos/

Dev approaches differ based on what you're working on. However, using 1 shared dev server is OK in most scenarios. See below.

  • Templates: Developers upload template code to Tridion via the Web GUI or Webdav (mapped drive). C# TBB code is uploaded with the TcmUploadAssembly tool. Shared dev server.
  • Core Service: Developers write code locally in Visual Studio and can point the WCF config to the shared dev server - and debug locally.
  • Event System: Developers write code on a Tridion Server (Dev with VS installed). It is possible to debug by attaching to the Tridion Service Host (Windows Service)
  • GUI Extensions: Best to use your own local VM since the chance you'll crash the GUI in your experiments is fairly high, and will make you less popular with your Tridion friends.

The text templates are versioned inside Tridion, which is usually good enough. However, it is good practice to put the C# TBBs in an external Source Control system like Git or SVN.

Finally, I would suggest to start following some Tridion bloggers, subscribe to get notification from the Tridion StackExchange, and browse around the Tridion Live documentation (some hidden gems there).

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.