Opendeploy: Suggestions for deployment

Hi,
Currently we have TeamSite folder structure as shown below
WWW
>Website1
*Staging
*Workarea
>Website2
*Staging
*Workarea
>Website3
*Staging
*Workarea

As we have development project and support (BAU) project running simultaneously for each website we are not sure how to split the project changes from BAU changes and deploy into different test environments (TestA and TestB) from a single webcontent branch in Teamsite.

Could you please suggest some ways to overcome this?

Many Thanks

Find more posts tagged with

Comments

Adam Stoller

Hi,
Currently we have TeamSite folder structure as shown below
WWW
>Website1
*Staging
*Workarea
>Website2
*Staging
*Workarea
>Website3
*Staging
*Workarea

As we have development project and support (BAU) project running simultaneously for each website we are not sure how to split the project changes from BAU changes and deploy into different test environments (TestA and TestB) from a single webcontent branch in Teamsite.

Could you please suggest some ways to overcome this?

Many Thanks

BAU? not a TLA I recognize - care to expand?
Also - I think you need to explain more fully what you're trying to do - the above explanation is still kind of vague to me - perhaps try providing a full use-case scenario that demonstrates the "problem".

karthikv

Thanks for your reply.
Basically we have single webcontent branch in TeamSite and there are many websites in this branch as shown in the earlier mail.

We have a development project and a Support(Business As Usual / maintenance) project running simultaneously. Support project is basically to work on Service requests or small changes.

We have come across a scenario where we need to deploy say 50 components to TestA environment(For Support project) and 100 components to TestB environment(For development project) from single Teamsite branch. At the moment we do this manually creating an edition comprising all the 100 components and deploying to TestB environment. But there is a risk of deploying other components related to Support project along with this.

Also as this is done manually this is a overhead for the developers.

We need to find out a way to overcome this i.e to separate the Project changes from the support project changes and deploy to different test environments.

A similar scenario of separating project changes to support changes can be handled in Rational ClearCase (Software Configuration Management tool) using a labelling concept where all the project related changes can be labelled with a label (Say Dev_Proj1) and support changes (Support_Proj) and later pick up the files using labels.

Hope I am clear.

Many Thanks

Adam Stoller

Thanks for your reply.
Basically we have single webcontent branch in TeamSite and there are many websites in this branch as shown in the earlier mail.

We have a development project and a Support(Business As Usual / maintenance) project running simultaneously. Support project is basically to work on Service requests or small changes.

We have come across a scenario where we need to deploy say 50 components to TestA environment(For Support project) and 100 components to TestB environment(For development project) from single Teamsite branch. At the moment we do this manually creating an edition comprising all the 100 components and deploying to TestB environment. But there is a risk of deploying other components related to Support project along with this.

Also as this is done manually this is a overhead for the developers.

We need to find out a way to overcome this i.e to separate the Project changes from the support project changes and deploy to different test environments.

A similar scenario of separating project changes to support changes can be handled in Rational ClearCase (Software Configuration Management tool) using a labelling concept where all the project related changes can be labelled with a label (Say Dev_Proj1) and support changes (Support_Proj) and later pick up the files using labels.

Hope I am clear.

Many Thanks

Okay - basically, for TS, you'd probably want to have a primary branch for main-line-support and a sub-branch for project work.

You have to develop your own process for managing the merges back-and-forth between the branches (from main-line to project to keep it in-sync, from project to main-line when the project is ready to be released to main-line)

The tools provided that you can use for implementing this are iwupdate and temporary workareas in which to perform the merge. These will help automate some-to-most of the process, but you have to allow for conflicts between the two lines of development that will require manual merging which may be do-able through the provided Merge GUI tool.

Some folks like to do the merging to the project sub-branches on regularly scheduled increments (weekly?) - some set up workflows to help the process so that when a submission to the main-line is made it is automatically merged into the project sub-branch(es).

The latter is pretty much the way Interwoven does their code development for TeamSite (or used to - I imagine they still do) - it involves configuration files (to specify what sub-branches to merge into) and usually some form of workflow instantiation or cgitask form to verify that those merges should occur and/or who should handle conflicts and/or who was responsible for reviewing the changes before-hand (it all varies depending upon your organization's needs)

In summary - you want a branch structure like:

/default/main
             /site1
                   /EDITION
                   /STAGING
                   /WORKAREA/****
                   /project
                           /EDITION
                           /STAGING
                           /WORKAREA
             /site2
                   /EDITION
                   /STAGING
                   /WORKAREA/****
                   /project
                           /EDITION
                           /STAGING
                           /WORKAREA
...

You can have multiple project sub-branches (project1, project2, etc.) and, if necessary, even have project sub-sub-branches (project1/feature1, project1/feature2, etc.).

Obviously, the deeper the tree, the more complex the process - but the general strategy remains the same - it just has to be applied correctly.

Hope that helps.

1.txt

2.txt