nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Managing future releases of a website

bturns

Hi There,

TS 6.7.2
Solaris 10

We are getting ready to create a solution for managing multiple releases of the same website. I would love to hear some recommendations on best practices, caveats, etc....

We need to:
1. Be able to create a separate copy (virtual copy) of a website for deployment to an environment.
2. Be able to easily integrate an upcoming release of a website into the current release
3. On going ability to move updates of a current release into future releases.
4. Track approval dates on content

I've seen this done in the past by having a branch for each release and then using workflow to move updated files between the branches.

Branch1 - current release (1.0 currently being deployed to production)
Branch2- future release (e.g. 2.0 release going live in 2 months)
Branch3 - future release (e.g. 2.2 release going live in 4 months)

Each of these branches should be able to deploy to environments for viewing, QA or UAT.

Another approach I've seen involves only one branch. Content in that branch is tagged with metadata that signifies which release the content is associated with. When a running a deployment a user will choose a release to deploy. The deployment will then push the content from the current release and also and content from the release that was chosen using metadata.

Anyways, I'd love to hear any thoughts on what approaches work and which ones don't work.

Thanks,

Brian

Find more posts tagged with

Comments

Bhargav Coca

In my opinion, as long as your releases are nothing but enhancements/improvements in styles and content you can follow any option you have listed. Simple Solution would be to cut an edition when it is ready for release and tag it accordingly. So you can keep your editions of a single branch and have snapshots of all your releases.

On Contrary, if there is third party involvement or changes in the functionality of the site and if you have many dynamic elements, feasibility of having a perfect snapshot become impractical.

You might have to maintain different area of your site in different branches and maintain version from those branches.

HTH

Thanks

Capture.PNG

Adam Stoller

I'd suggest the multiple-branch concept over the metadata concept.

From a very basic standpoint, you cannot have multiple versions of the same file in the staging area of the same branch - so saying that version-1 belongs to this release and version-2 belongs to that release, and then having to update version-1 for this-release without then breaking things for that-release is ridiculously convoluted.

Don't bother thinking about using different workareas for different releases (on the same branch) - its a losing proposition that does not take into account the way the product works.

Branches, perhaps with metadata - is generally the way to go - you may need a few configuration files too, to keep track of which branches can deploy to which target paths of which receivers, etc.

Rick Poulin

Don't bother thinking about using different workareas for different releases (on the same branch) - its a losing proposition that does not take into account the way the product works.

Depends on the use case.. I had a client where this model made perfect sense. The "main" workarea was for the BAU typos and emergency fixes. They could then create a new workarea for all changes that had to do with updating the site for the upcoming release of version X of a product. The key is (still) in the workflows. A "publish to preview" workflow sent the changes to a preview server and DID NOT submit to staging. A "publish to live" workflow took them through the process of merging with "main" and deploying and submitting and doing the 'get latest' wherever it needed to be.

Yes, we could have done this with multiple branches just as well, but it did keep things cleaner (they had enough branches as it is). The key point is that in their use case, the release wasn't a new site on its own. It was a bucket of changes that were intended to be applied to the 'trunk' eventually. The live site always was an exact match of what was in staging, so their business process with respect to temporary 'grouped content changes' for a release was analogous to TeamSite's workareas concept.

'course this whole idea gets scrapped as soon as you start talking SitePub.

Sean_Hanck

To echo Rick, it really does depend on the clients install. Workareas are there for exactly that reason (I'm sure there are a whack of additional ones too, like access control). If you have a custom presentation layer, or one that previews inside TeamSite (most of my implementations), this should be the path. If you are going down the path of tightly integrating your presentation with Autonomy products (ie: SitePublish and LiveSite), then yeah think of another solution.

The advantages of the using the workarea approach, is that the tool does a lot of the library services that are required with out the need for much configuration or customization (things like merging, detecting differences, etc).

Think of STAGING as the head in CVS and the workareas as the branches...

Adam Stoller

To echo Rick, it really does depend on the clients install. Workareas are there for exactly that reason (I'm sure there are a whack of additional ones too, like access control). If you have a custom presentation layer, or one that previews inside TeamSite (most of my implementations), this should be the path. If you are going down the path of tightly integrating your presentation with Autonomy products (ie: SitePublish and LiveSite), then yeah think of another solution.

The advantages of the using the workarea approach, is that the tool does a lot of the library services that are required with out the need for much configuration or customization (things like merging, detecting differences, etc).

Think of STAGING as the head in CVS and the workareas as the branches...

You cannot think of workareas as branches because they aren't branches. Branches provide for versioning - workareas do not. Any attempt to use workareas as-if they were branches is fragile at best.

Using a temporary workarea to do some short-term, well-scoped development work that's destined for the main "release" is fine. Using temporary or permanent workareas to do long-term and / or poorly scoped development work is (IMO) a poor decision for TeamSite.

All it takes is one person to submit one file from one workarea to pollute the "head" of the release version

All it takes is one person to do a Get Latest in a workarea to forever lose all non-submitted changes that were being worked on for a subsequent release.

(If you have your backing store on a NAS with snapshots configured, you might be able to recover most, if not all, of the changes - but I wouldn't want to depend on that if I was working on an N-month development effort)