nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

preview deployment vis production deployment

ShovelFace

Using OD 6.1 on Solaris.

Wanting to use same script for filelist deployment, where when deploying to preview server, content is sent from workarea (done). What are the recommendations for ensuring that the production deployment is ultimately the same as the content in STAGING? For example, should it be the following:

- get approval in workflow
- deploy file from WORKAREA to production server
- submit to STAGING

or

- get approval in workflow
- submit to STAGING
- deploy file from STAGING to production server

Any input greatly appreciated.

Find more posts tagged with

Comments

msrinivas

Second one. Workarea has things that are WIP.

ShovelFace

Granted, but once the "approve" is done in the workflow, the thinking was that it is no longer work in progress, and can then be deployed from the workarea and then submitted to STAGING. This would ensure that STAGING is not overwritten should the deployment fail. If the deployment is successful, then STAGING is updated.

Adam Stoller

Granted, but once the "approve" is done in the workflow, the thinking was that it is no longer work in progress, and can then be deployed from the workarea and then submitted to STAGING. This would ensure that STAGING is not overwritten should the deployment fail. If the deployment is successful, then STAGING is updated.

In theory, you're right, but Best practice dictates deploying from staging or editions and never from workarea. As long as you submit the files to staging directly after they've been approved - they are no longer a moving target (well, at least not a fast-moving target) and you significantly reduce the possibility of deploying something to your production servers that hasn't been approved.

ShovelFace

My preference would be to deploy from STAGING. However, how does one roll back from STAGING should the deployment fail? Or is the idea to fix the deployment and redeploy from STAGING?

Lastly, can file deployments be done from STAGING? I have issues doing so, but more likely an issue with the code.

ShovelFace

If the dcr submitted from the workarea is in

//cms-dev/default/main/AAA/Internet/SubA/WORKAREA/SubA/templatedata/news/release/data

I would need to convert the deployment path to
//cms-dev/default/main/AAA/Internet/SubA/STAGING/templatedata/news/reelase/data

In other words, change WORKAREA to STAGING, and remove the workarea reference SubA.

Is the best way to do this using regex? Any thoughts on syntax?

msrinivas

Can I get your thought behind deploying DCRs to the webserver? I hope you know they are not needed to be on the webserver once you generate your pages.

ShovelFace

Sure. The pages are not being generated on the back end. The DCRs and EA are being pushed to the front-end, at which time they will be assembled into the presentation layer.

Comments?

Adam Stoller

My preference would be to deploy from STAGING. However, how does one roll back from STAGING should the deployment fail? Or is the idea to fix the deployment and redeploy from STAGING?

Lastly, can file deployments be done from STAGING? I have issues doing so, but more likely an issue with the code.

The general notion is that if the deployment fails - you retry / fix the deployment - STAGING represents what you want to put onto the web server - you don't want to roll that back just because the deployment failed.

However, if you find you need to roll back STAGING (either in part, or in whole) you do that by populating a workarea with the version of the file(s) you want in STAGING and re-submit them.

And yes, filelist deployments can be done from STAGING - it's very common.

If the dcr submitted from the workarea is in

//cms-dev/default/main/AAA/Internet/SubA/WORKAREA/SubA/templatedata/news/release/data

I would need to convert the deployment path to
//cms-dev/default/main/AAA/Internet/SubA/STAGING/templatedata/news/reelase/data

In other words, change WORKAREA to STAGING, and remove the workarea reference SubA.

Is the best way to do this using regex? Any thoughts on syntax?

Yes - a simple regex in the code used to create the filelist is all that is needed and often used. You shouldn't really need help with this, but I feel a tiny bit generous right now:

$path =~ s|/WORKAREA/[^/]+/|/STAGING/|;