web site versioning and source code management

This subject has come up in another thread and seems important enough for a new thread.

There seems to be more attention for "the convergence of code and content" (e.g. TeamCode announcements, the interview on the homepage, etc).

There is also an Interwoven best practices document about Life Cycle Management available. It discusses the separation of Development, Integration and QA-branch.

Although this document is useful, it misses the combination of code and content (maybe it was written before the time that issue was invented).

So I'm curious how others are dealing with this issue.

Yes, the project I'm working for now uses a formal approach including Dev, Int and QA systems. But we often stumble into the problem of the simple content (e.g. the plain HTML content). E.g. when we create new JSP's for our website, it includes a number of html-pieces that are entered by filling in data capture forms. So it is essential that code and content changes go life at the same time.

The simple process of creating an edition in Integration and CopyToArea that to a workarea in QA often leads in our case to conflicts of the static content. This might be partly due to a bad design I admit, but I expect we are not the only ones experiencing this problem. Life content changes more often than scheduled application releases, that's a fact of life.

We don't use TeamSite as source code mngt tool, just the end results of a development activitity (the executables or jar files) are imported into TeamSite.

So we use TeamSite as "website versioning tool" and not as "source management tool".

What I've heard about TeamCode is that it might be possible to do source code management that way. But I don't think my current project is interested in that, they will stick to their application versioning system for application development.

So, I've shared our approach. And I hope to hear others.

Thanks in advance!

Find more posts tagged with

Comments

HarryH

We are facing the same problem as yours.

This problem is complex especially when you want to separate code and content in JSP pages with server-side-include. The content keeps changing frequently while you develop code. How do you sychronize two development environment?

We are trying to completely seperate the code and content development environment. We don't want to deploy code through teamsite.

Pavan

I am a newbie. I am going to start the Teamsite integration project in a week. And the first question I had was the same as this one. How do we synchronize our code and content ?

We have our Java,JSP Code in Source Control System (PVCS) outside of Teamsite and HTML and JSPs which are included are in Teamsite.
So, how do you allow Authors to preview the HTML in context of an entire JSP page ? Do you keep one copy of all JSP and Java Code in Teamsite ? If yes, then how do you synchronize these two systems ? Is there any automatic process or its a manual process ?

Any insight will be appreciated..

Migrateduser

You've basically described what we see as best practices for managing code and content together. Developers work in the DEV branch, when an integrated build is ready it's promoted to the INTEGRATION branch where all the business users are creating content...if a new version of the application logic is ready from DEV it can be promoted up to INTEGRATION and not affect your content contributors until the INTEGRATION manager is ready to utilize it.

In order to enable business users to see their content changes in real-time, via virtualization, the code + content must be managed together. Once this is setup, products like the TeamTurbo automatically package, deploy and sandbox the applications so one workarea changes don't affect other workareas and OpenDeploy can be used in conjunction with TeamTurbo to deploy the applications to your production servers. Since content does change 10-25X as fast as code, does it really make sense to only let people see their changes after the code and content have been taken out of their respective systems, moved to a preview server, see how things look, and then go back into the separate systems to make changes and do it all over again. For some customers, it takes a week for a graphic artist to see what their new image looks like in the context of the application because they separate their code and content and only enable simple preview, through manual processes on a separate preview server. Using technology already available to you--virtualization--provided OOTB for HTML/ASP and via TeamTurbo for JSP-J2EE users can collaboratively preview their content changes in real-time and in-context of the application logic.

Assuming you're promoting new versions of the logic periodically to INTEGRATION and content contributors are making changes until the application--CODE + CONTENT--is ready for QA you should have the latest of both being promoted to QA together. If once the app reaches QA you realize either the code or content needs to be updated again...you can promote another edition from INTEGRATION. If code changes are required those should be done in DEV and then promoted to INTEGRATION so you can control who has access and still logically separate code baselines (coming from DEV) and entire application baselines (coming from INTEGRATION) if you want.

This is a complex issue, TeamCode will reduce some of this, but the bottom line is to best support all users working on your sites...the code and content need to be managed together. The J2EE specifications require this as well. TeamCode will let you continue to use your existing SCM system and just make it easier to manage the release of code+content or it can be used to manage both the code and content from the beginning without developers changing the way they work...this is what the IDE plugins help provide. TeamCode can coexist and or consolidate your systems and this can be configured on a project by project basis.

Migrateduser

Customers have done it manually and have automated it. Some have built buttons into the SCM tool to push a baseline into TS on demand, others have written their build scripts to put a copy of the executables into TS, and others have setup complex manual procedures on when and how code baselines should be brought into TS and dovetailed with the content. For the most part, customers have tended to use TS's publishing model to release the application, consisting of the code and content, as Editions vice moving content into and SCM system and releasing from there.

The white paper (technote 048788), around which TC is designed, describes our best practices for managing a release. In the INTEGRATION stage is where your business users work, in the DEV stage your developers.
If you want to continue using PVCS--that's fine and probably preferred so you don't upset you development team needlessly--just setup your processes (more political than technical) to bring the code--binaries or even source--into a TS DEV activity and then use workflows, support for all user types via templating, file-system interface, etc...e-mail notifications, external call-out capabilities and virtualization to manage the lifecyle of the release.