Guru guidance: DEv to SI to QA to LIVE code deployment

Hello,

We are currently setting up an interwoven based system (Teamsite, Sitepublisher/Livesite, Opendeploy) to replace our old in-house CMS and manage our website.

We will be setting up a number of different environments for development, QA, etc. Our goal is to enforce a strict process for reviewing "code" changes (so templates, components, etc - basically anything that isn't content) before they go live. Whilst content contributors will pretty much work only on the live system, code developers will work on their own system, then package the code for deployment on the integration system, then send their code to QA for review, after which (if it passes) it can be deployed to the live system and used by the content contributors.

Is anybody here doing something like this today? Any tips or tricks? Any gotchas? How easy is it to set up Opendeploy to transfer templates and components from one Sitepublisher installation to another? Should we be looking into workflows to manage the "routing" of code between the different environments? How do you handle those "emergency release" scenarios when a template or component (or other "code" but) needs to be changed *right now* and the QA staff are off for the weekend? Also, do you ever sync "backwards" (ie copy live content to say the dev environment so that you can work with more "realistic" content and volumes)?

I am interested in hearing any thoughts you may have on the matter. Thanks in advance for your time.

Regards,
/t

Find more posts tagged with

Comments

ISCBorisB

Hello,

We are currently setting up an interwoven based system (Teamsite, Sitepublisher/Livesite, Opendeploy) to replace our old in-house CMS and manage our website.

We will be setting up a number of different environments for development, QA, etc. Our goal is to enforce a strict process for reviewing "code" changes (so templates, components, etc - basically anything that isn't content) before they go live. Whilst content contributors will pretty much work only on the live system, code developers will work on their own system, then package the code for deployment on the integration system, then send their code to QA for review, after which (if it passes) it can be deployed to the live system and used by the content contributors.

Is anybody here doing something like this today? Any tips or tricks? Any gotchas? How easy is it to set up Opendeploy to transfer templates and components from one Sitepublisher installation to another? Should we be looking into workflows to manage the "routing" of code between the different environments? How do you handle those "emergency release" scenarios when a template or component (or other "code" but) needs to be changed *right now* and the QA staff are off for the weekend? Also, do you ever sync "backwards" (ie copy live content to say the dev environment so that you can work with more "realistic" content and volumes)?

I am interested in hearing any thoughts you may have on the matter. Thanks in advance for your time.

Regards,
/t

It's a normal practice to use TS itself to manage TS code, both *iwstore* (templating components) and *iwhome* assets.
Yes, approval Workflows are a good idea and Open Deploy is a very good instrument to promote components between
various environments like Development, QA, UAT, Production and whatnot. *Emergency* Deployments are often covered
by either dedicated Workflows with limited access or by granting "self-approval" credentials to certain members of your team.

All these are trivial considerations though. It is far from trivial to get it all designed and implemented correctly or to get
funding/resources for it for that matter. If your Company has established code management software and procedures
in place (CVS, PVCS, Perforce, ClearCase, you name it) it is often beneficial to not reinvent the wheel and simply use existing
technology for TS code as well.

tanguyr

Hello,

All these are trivial considerations though. It is far from trivial to get it all designed and implemented correctly or to get
funding/resources for it for that matter. If your Company has established code management software and procedures
in place (CVS, PVCS, Perforce, ClearCase, you name it) it is often beneficial to not reinvent the wheel and simply use existing
technology for TS code as well.

We do currently use ClearCase for our java app code, but we were hoping to move away from it for web stuff (politics. don't ask). Since TS can version our web code files, what would we gain by storing them in ClearCase? Also, i understand that things like components and templates depend to some extent on metadata stored in the TS file system. Would i have to extract this in order to store it in clear case? This last point also brings up a question about OpenDeploy: so far i've used it to deploy from TeamSite/SitePublisher to LiveSite Runtime, but not from one instance of TS/SP to another. Is there an easy built in way to tell it "deploy these files and their metadata" or will i have to code a custom solution?

As for the emergency deployments, i think your solution of letting certain "super admins" do this is a good idea for our setup - in case of probs the operators already call in a developer today, so giving these guys the ability to make required fixes straight in live is probably the easiest way for us to go.

Regs,
/t

ISCBorisB

Since TS can version our web code files, what would we gain by storing them in ClearCase?

A lot. Do I really have to list benefits of unified Code Maintenance, Version control, Back-ups, Roll-backs, Support, Training and whatnot?
IMO, all that should not depend on particular Project or Development domain. It's one thing to "move away from it" completely (supposedly to better one),
to do it only for "Web stuff", whatever it could possibly mean is questionable at best. Code is code is code.

things like templates depend ... on metadata stored in the TS file system. Would i have to extract this in order to store it in clear case?

TS functioning in some cases depends on stored metadata. Templates proper (or other TS code) do not have it.
So, unless you are designing something very unusual you can keep TS Code components in CV's just like any other code.

Is there an easy built in way to tell it "deploy these files and their metadata"

Starting with OD 6.0 an ability to Deploy Data/MetaData together is a built-in functionality. Sure enough, you'll need
target Environment that can accept TS Extended attributes. That said, from the previous point it should be clear that
this feature is irrelevant to Code management issues