Deployment on Staging Server

Can anyone give some guidelines for deploying content first to staging server and then to production (live) server.

I need to know the steps to be followed (importing, setting permissions etc) . for submitting and deploying a single . shtml file for an instance.

The platform is Windows NT
Teamsite version is 6.1.0
Logged in as Master
UI is Content center Professional

Find more posts tagged with

Comments

pwb

Wagh,

My organization also deploys to different environments.

We have a need to deploy to both a Staging and Production environment. The Staging environment is used to obtain site owner approval of new content. Currently any new projects or content for on going maintenance in need of approval is deployed from a workarea. The new/modified content is not submitted to TeamSite's staging area until it is approved for production. The staging deployment is executed using the command line.

We are trying to find a solution that will allow content to be submitted to TeamSite's staging area so it can be version controlled and be easily re-deployed to production upon approval. Our problem is that the site cannot be frozen waiting for approval. In other words, if a project has been deployed to our staging environment and is awaiting approval, there may be some press releases or product updates that will be deployed to production before the project files are. All of our deployments are currently based on an edition comparison. To further complicate, we are trying to only the execution of deployments using the OD GUI.

Any feedback on how to accomplish this or other strategies employed would be greatly appreciated.

Edited by pwb on 05/04/05 12:22 PM (server time).

Nicholas

IIt will be good if you can post this in OpenDeploy forum, always good to get specific and early response.

Well detailed information and steps available in "OpenDeploy Administration Guide".

Thanks Nicholas

ExecuteReport.zip

Bowker

Wagh,

Our environment is a little more complicated and I have implimented a solution that has worked for about 2 years now with success. Before I get too far, hind-site is always much clearer and I would probably have used sub branches instead but....

Our deployment path is Preview-SystemTesting (1st Level), Preview-UserAcceptanceTesting (2nd level), Production, for business partner changes (content changes). The Deployment path for new types of content, new presentation templates (XSL and TPL files) is along the same idea, but on different servers. That path is localhost, System-testing, UserAcceptance testing. Once that is successful, then we move those changes into the "preview..." path so the business partners can make sure changes are correct with 'production' data.

A pain in the neck? yes
Do we follow all 5 steps every time? no
Have we had to back anything out due to error? not in a very long time

For business-partner changes (content) we have 4 different work areas (Development, System, UAT, Prod) and we use workflows to migrate content from one work area to another. As data is copied to another workarea, it is also deployed to the associated preview environment. When files hit "production" they are submitted.

As you look at files along the chain, the content gets "cleaner". The files in Development are pretty dirty, with partial edits and unapproved changes. About once per month (or quarter), at the business-partner's request, we will delete the testing workareas and recreate them from staging to 'clean-up' their stuff, but that takes a bunch of coordination that we don't kill something.

For the 'technical staff' changes, we have one workarea per project created and we do manual deployments to the other test areas. Since there are only 4-6 of us we talk about who is using which 'testing' server so ensure we don't mess each-other up.

As you might imagine, I've described the tip of the iceburg. Most of what we do and the procedures associated are what lies under the water.

Good Luck

Dan Bowker
Northern Trust
Web Publishing Technology