Dev/Prod Synchronization Strategies

We want to deploy from our development environment to the production environment and from the production to the development on a scheduled basis. Our concern is that we might run into synchronization issues. I will explain it in more detail.

The developers will be working on the dev and authors will use prod. Deployment will be done from the dev to prod and vice versa. If a developers work is in the dev it will be overwritten, for example, when deployed from prod to dev.

What is the best way to tackle this issue. Any suggestions/comments/solutions are welcome.

Appreciate your feedback,
Thanks,
Reeturaj

Find more posts tagged with

Comments

Adam Stoller

Why are the authors working directly on the production servers?

Is the location of the assets (within a directory structure) where the authors work and where the developers work distinct? Are the files that the authors work on *never* modified by the developers - and vice versa? If so, you could use source and/or target side filters in your deployments and synchronize that way. However I'm still rather concerned that you have an awkward (at best) process.

--fish
(Interwoven, Curriculum Development)

reeturaj

The locations are not distinct, it will be the same. The files worked by the authors will be modified by the developers and vice versa. We are planning this type of process mainly because once the pages will be authored by the authors in prod it can be deployed to the portal servers. The developers will only work on the dev. We do not want development work to directly go to the portal servers. Our main concern is that once deployment is done from the prod to dev the developers work will be overwritten.

The process is not yet finalized. From the prod box we will be deploying to the portal server. We have teamsite installed in both dev and prod. Is there a better and elegant solution for this process. If you require any other details let me know.

Appreciate your response

Adam Stoller

Are the files modified at least distinct?
If so - and you only deploy the newer files in either direction (prod->dev, dev->prod), I *think* you'll be okay (the lack of conviction is due in most part to not truly understanding your process).

I think part of my confusion is over what you are calling "prod" vs. "dev" - as you now indicate that TeamSite will be on both servers, I can only assume that these are, to some extent, both *development* servers - so I will think of them as "prod-dev" (authors), and "app-dev" (for lack of a better term right now - for your developers) - and finally you have the portal servers which I normally think of as "production" - but I'll call it "final-production" to try to make the terms distinct.

As I said, you could deploy in each direction "prod-dev" -> "app-dev" and "app-dev" -> "prod-dev" into distinct "upload" workareas on each server. Distinct in that the "local" (sorry about all the quotes) users of that particular server do not perform any development there. Assuming you only deploy *newer* files (the default behavior of OpenDeploy) - what you would want to do is have a DNR script that runs on the target side *before* the deployment, that performs an iwupdate ("GetLatest") of the "upload" workarea from the STAGING area - then perform the deployment, and then perform a DNR script on the target side *after* the deployment [on success] - that performs an iwsubmit operation.

In this way - both servers should be synchronized - and then, presumably, you would verify / QA the work at certain points in time on the "prod-dev" system before finally deploying everything out to your "final-production" portal servers.

Does this sound about right?

Again, it's a little difficult discussing this in a forum like this (as opposed to being in the same room with a view of your servers and a white-board to brainstorm on).

--fish
(Interwoven, Curriculum Development)

reeturaj

The design you suggested will be appropriate in our case. Thanks, for explaining it so clearly. I have couple more questions.

Will the DCR's changed in one environment( say prod-dev) be reflected in the other environment( say app-dev) after it is deployed. I guess it will be reflected since we will be deploying everything in staging. I just wanted to double check.

Also since we will be deploying everything in Staging from prod-dev to app-dev and vice versa which deployment type will be best suited.

Appreciate it,
Reeturaj

Edited by reeturaj on 09/09/02 02:35 PM (server time).

Adam Stoller

Glad you asked - because I neglected to cover something.

When you deploy files with TeamSite Extended Attributes (EA's) - such as DCR's, files generated from DCR's, and assets tagged by various other Interwoven products [MetaTagger, VisualAnnotate, etc.] - those EA's do *NOT* get transferred by OpenDeploy.

Instead you will need to record the EA's (DNR source-side, before deployment), transfer that data and re-apply it on the target side (DNR target-side, after deployment [on success]).

I believe such a script for doing this has either been posted or is available on the Support site in a KB - if you cannot find it, please contact Interwoven Support as they should be able to provide you with a known-working version.

Without the EA's DCR's will not be recognized as such, and generated files will not be able to be regenerated - and anything else which you may have used EA's to record will no longer function as desired.

You might end up wanting to use a workflow that kick's off the initial asset deployment, then using a DNR (source side, after deployment) capture the list of assets deployed (see IWODHOME/solutions/perl and the OpenDeploy manuals) - and then just transfer EA's associated with that list of files in a second deployment - though that does leave a "window" open in which the newly transferred assets will not have their EA's associated -- so ultimately it's up to you as to what approach you want to follow (trying to do it all in one fell swoop, or doing things in stages).

As for which deployment type will be best suited - I'd recommend a sourceFilesystem deployment *without* filelist - such that a comparison is performed between the source and target areas.

Of the three "types' of deployments, this is perhaps the slowest [not necessarily slow, just slowest of the three] - but it is definitely the most accurate in terms of deploying changed files.

--fish
(Interwoven, Curriculum Development)

reeturaj

Thanks for all the feedback. We are now planning to have three branches in App-dev(dev,Int,QA) . The flow will be from dev -> int -> QA in App-dev. From QA branch it will move back to dev branch and also deployed to prod-dev. There will be no branching in prod-dev. From prod-dev it will be deployed back to dev and the portal server.

Any suggestions or scope for improvement with this enhanced design will be appreciated. Any feedback will help us to incorporate it in our design.