Moving Livesite related stuff from DEV to PROD

How you guys are moving the stuff from DEV to PROD? TeamSite/LiveSite - Components, XSLT, Pages, Templates, DCRs. Simply copy all folders from DEV to PROD with the help of admin or ?

Find more posts tagged with

Comments

Reji Varghese

Best is to create a SPAR file in DEV and explode the .spar file on PROD.

The creation of spar is explained in the guide.

Rick Poulin

The SPAR is an option, but there's essentially no good answer -- you pretty much have to create something custom one way or another. The easiest approach might be to use OpenDeploy, if we're only talking about content.

Whatever you do, build something that's repeatable and traceable, so you avoid human error and unexpected behaviour.

test.rptdesign

reporting.js.txt

Srinivasa Talla

Creating spar file - issues

Other guys having issues with spar files.

The easiest approach might be to use OpenDeploy, if we're only talking about content.
 
Whatever you do, build something that's repeatable and traceable, so you avoid human error and unexpected behaviour.

Rpoulin, how you guys are doing that? by writing deployment script from DEV TeamSite to PROD TeamSite or any other way?

Rick Poulin

Long story short, we've developed our own tool to automate code builds. I've been consulting around this platform for ~10 years now, so my requirements for a ready-made generic and modular build process is probably way beyond what you need. If you ask folks like ghoti and nipper, they have their own versions of that too.

The general approach is this:

Decide what is "code" (managed by teamsite devs) versus what is content (everything else). Things like workflow code and page text are obvious extremes, but XSL, CSS and JS are often debatable.
"Code" should be managed in a source control repository. The actual folder structure matters little -- do what works for you. You want a reproducible way to move that to any target server, so it's imperative that DEV is installed in the same paths as PROD. Automate this process (via script or whatever) as much as possible. That way, whatever you deploy and test on QA is exactly the same as what you eventually put in PROD -- no surprises.
Some people prefer to write code on a DEV server and then have a process that copies that code to another location for source control, and uses OD to "promote" the code to QA and PROD. I don't personally like this approach because there's room to 'forget' to include files, and because it's harder to identify what's custom and what isn't. But to each their own.
"Content" doesn't follow the same process. It should always be created in production and validated using 'preview' (either TeamSite preview or an actual preview runtime server). Once in a while, we backwards-sync DEV and QA by taking a copy of the production content store and putting it on those lower environments. But content should never be written in QA and then "promoted" to production -- that defeats the purpose of the teamsite architecture.

Srinivasa Talla

Excellent! I appreicate that. Yes, different people follow different ways. But you explained your way, thanks alot.

nipper

A lot depends on your needs. As a project starts you will do large deploys and likely use a spar or something similar.

As you get into maintenance mode, you will have a css here, js there and component update later. That I typcically do with an download and import.