Need Help for Environment Promotion Workflow

We have TeamSite 7.4.1 with SitePublisher and OpenDeploy.

We typically have three content environments: Development, QA and Production.

These are represented as branches in a single TeamSite store.

I think what I would like to do is have a process that:

When initiated in the QA branch it creates an Edition and moves that Edition to the QA branch then uses OD to deploy the Edition to the actual QA web servers.

When initiated in the Production branch, it takes the supplied Edition from QA and moves it to the Production branch and then uses OD to deploy the Edition.

I'll add the appropriate approval steps once the base functionality is working

I poked through the out-of-box workflows and found that the Submit_Archival_Workflow has tasks that create an Edition and deploys it via OD.

In trying to understand the workflow functionality, I went through the tutorial in appendix A in the Workflow Modeller User Guide.

So here my questions:

General -

- Are the available URL tasks documented some place? For example, the Create Edition task in the archival WF uses an external URL task which specifies com.interwoven.ui.archivalmodule.workflow.task.urltask.EditionCreationTask and some other parameters. How do I know what parameters to supply or even if we have this module? Or even if it does what I need it to do.

I found a lot of URL tasks defined in various commands.xml files but most say they are for internal use only!!!

- Same question about CGI tasks and external tasks.

Specific to this solution -

- Can an Edition be copied from one branch to another in a workflow? If so how? OD? Some URL, CGI or External task? Even if it needs to be copied to a work area first then submitted, that's fine but I need to know how to copy the edition.

- Any other suggestions on how to do this "promotion" activity? I'm not married to Editions. Fundamentally, the requirements are: people work in development then request a promotion to QA which involves deployment to a QA server. Multiple QA deployments may happen for each Production deployment as things are fixed. Once finally approved in QA, that "snapshot" needs to be deployed to the production servers.

Any help is appreciated. Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

To the best of my knowledge, editions cannot be copied from branch-to-branch; rather one copies the files from the edition on one branch to a workarea on the other branch - then you submit and publish the edition on that other branch (though you may want to have some steps of testing / verification before doing so - up to you).

Some of the OOTB programs / scripts / classes are documented - but most are not - instead the documentation covers how to create them - and the onus is on you to plow through things like the CSSDK documentation to write your own code to do what you want if the OOTB classes don't work for you. Most developers will first spend time de-compiling the OOTB java classes to understand what they are doing and what parameters you can provide them. If you're comfortable with that - do it (this is not modifying the OOTB code, just getting to it so that you can understand how to interact with it). After that, it's a case of how much you need features or functionality that aren't in the OOTB pieces.

If you are using OS accounts - you have the flexibility of using Perl or Java to write your customizations; if you are using LDAP-only / "Non-OS" accounts - you pretty much have to work with Java / CSSDK (not necessarilly a bad thing, just that it involves more up-front overhead to do the development work [IMO])

My advice - make sure to fully document your intended design / implementation before deciding what you can use OOTB vs custom coding. You could easily save hours / days / weeks or more of time that might be spent trying to implement something that in the end doesn't actually do what you want. Make sure to understand the whole process before trying to delve down into the specifics of code.

Beyond that - have fun!

nipper

I question this design.

I (as well as Ghoti and others on this board) have been working with TS for 15+ years.

Early in the IWOV career, this design was common. However people have moved away from the concept of release branches. With the implementation of SP, this is quite uncommon.

So take a few steps back and explain the business problem you are trying to solve and maybe someone here can offer a better solution.

If you are really trying to implement Dev/QA/Prod runtimes, and that is the only thing, there are different approaches.

One more question, if you have mulitple branches, how are they modified ? Or are all changes on the Dev branch and changes migrated to the other branches via workflow? You could make child branches and then merge/copy to from Dev -> QA -> Prod

WGM

Thanks Fish. I'm not sure I can decompile as licenses usually prohibit reverse engineering and we have policies against it too (so we are in compliance).

Given that you confirmed what I suspected regarding writing directly to STAGING/EDITIONS, I'll search more and what the requests from the UI as I simulate what I want to do.

OD seems to be able to more the files to a work area so that might be part of the solution.

However, if any one has more information or a different way to do this tings, I'd appreciate the information.

WGM

Hey Nipper, that is why I provided a bit more than just my questions.

From the requirements perspective, the requirements are not well defined.

Fundamentally, need to support our process which is:

Several interations of development.

At some point, the entire site must be viewable for review and approval in a model that is as close to production as possible (in other words, on real servers not through preview). This usually requires many interations.

Upon appoval, the approved "snapshot" becomes available in production usually on a scheduled basis. In other words, once approval is obtained, we would schedule for deployment at 9pm.

Promotion to production requires business approval.

Promotion for review QA MAY require approval.

For legal reasons (health insurance is highly regulated), the history of production must be retained so that the site as served on a given date/time can be retrieved.

I forget to mention that we do NOT use LiveSite. Our sites are currently HTML and NOT running under the LS runtime

I guess this could be done through one branch by creating EDITIONs when the site needs to be reviewed (QA'ed) and deploying a specific EDITION to QA. Then if it is approved, the EDITION can be scheduled for deployment.

The only parts I don't like are:

Assuming one workflow runs the whole thing, the job would have to hang around while the edition is reviewed. Then ultimately the approver approves or rejects. If rejected, the job ends. If approved, the job schedules the deployment (or it is put into a pending status).

The other issue is going to be some files must differ between QA and PROD. The sites we development in TeamSite are 99.9% content but they often link to other "active" application sites. In QA, these need to be the QA version of the app and prod is obviously the prod version.

The final issue is that it will be hard to determine which editions went to PROD unless there is some way to mark them as such or copy the edition that was approved to a name that indicates the edition went to PROD.

Is that more along the lines of best practices?

Any suggestions on how to achieve the above would be welcomed.

nipper

This is overly complex. But I do understand the issue, having done healthcare before.

Something like this does not lend itself to a soundbite, but people do design solutions in the cafertia on the back of a napkin.

The first thing I would try is:

Create a QA branch as a child branch to the main content branch.
Create a Prod branch as a child branch off of QA
Do development on the main content branch, in a custom workflow, use an update task to push content to the QA branch.
Kick off (automatically or manually) a workflow on the QA branch to go through the approval and deployments, completing in an update task to push the content to the Production branch.
Repeat step 4 on the Prod branch.

This may require a completely new WF, or you may be able to customize the PLC workflow for each branch. In either case this won't be trivial.I hope you are not in a rush.

WGM

Nipper, I missed your question at the end

"One more question, if you have mulitple branches, how are they modified ? Or are all changes on the Dev branch and changes migrated to the other branches via workflow? You could make child branches and then merge/copy to from Dev -> QA -> Prod"

Not sure I completely understand the question. But I'll try to answer. Changes only occur in DEV. Then they go to QA. Once approved they go to PROD. I can't say changes always originate in DEV. However, only in extreme emergencies would something be changed directly in QA and almost never directly in PROD. The QA and PROD branches only exist for the purpose of hold what can from the "upstream" environment. No work is actually done in QA and PROD.

WGM

Ha! I'm always in a rush

So what I think you are suggesting is a structure like:

Site (ie dev/where people work)

- QA

- PROD

Then through workflows, "push down" when required and starting a deployment from either QA or PROD.

If I understand, my questions would be:

- Is there an inherent avantage of having the child branches? My first thought was just to have Development, QA and Production as peers. Example:

Site (no work is done here)

+ Development
|

+ QA (no work is done here)

- Production (no work is done here)

This is how our TS 7.2 store is structured but that doesn't mean we knew what we were doing when it was set up. Additionally, our TS 7.2 managed websites sites are a completely different model using EARs and JSPs. This has caused a lot of restrictions and issues during deployments.

- Second question is in the child branch solution, does STAGING or EDITIONS within QA and PROD play a role or do we just lockdown a work area in each. I think EDITIONs are required at least in PROD for the audits...

Thanks for your time.

nipper

Question #1, the child branches will (or at least used to) allow you to use the update task to reference content from one branch to another. I have not done that for several years, so you will want to POC it.

Question # 2 is more political rather than techical in nature. I would expect that deployments would be done out of the WA and editions created after the submit and deployment completes.

WGM

Thank you. I'm having a go at a POC.

Adam Stoller

The only potentially significant advantage of using sub-branches as opposed to sibling branches is with regard to things like:

inherited roles and access rights
regex's for workflows and templates and such
visually reinforcing the process model

In and of themselves - there's no real difference between a sub-branch and a sibling-branch - each will have their own set of versions for the files that are stored there, separate staging areas, separate editions.

The staging area plays a role in all three branches:

DEV: versioning of files under development (many versions likely)
QA: versioning of files that have been reviewed and approved within the QA environment (fewer versions than development)
PROD: versioning of files that have been reviewed, approved, and pushed to the production environment (probably fewer versions than exist in QA)

The editions are, as you indicated, most importan in production, but it makes sense to keep track of them in QA too. For development, snapping editions when you've gotten approved changes to QA is reasonable (though depending on what other processes may be available in the DEV branch, it may or may not be "fool-proof")

WGM

Thank you both, Some good things to consider.

I'll play around some and see how things go.

Adam Stoller

nipper wrote:

[...]
Question # 2 is more political rather than techical in nature. I would expect that deployments would be done out of the WA and editions created after the submit and deployment completes.

If we are talking about SitePublisher pages - I believe the deployments (at least as done via the PLC) must be done from the workarea - as the overall process involves setting some metadata on the files which will fail if attempting to deploy from the staging area or an edition.

There may be a way around that limitation - but the general rule of reveiw-approve-deploy-submit is generally the norm.

nipper

ghoti wrote:
If we are talking about SitePublisher pages - I believe the deployments (at least as done via the PLC) must be done from the workarea - as the overall process involves setting some metadata on the files which will fail if attempting to deploy from the staging area or an edition.

While that is the default, it is not required. Certainly not easy to change, but doable.

IMHO, I agree with the deploy from WA. You rae only deploying objects in the job, so I am not grabbing someone else's changes. If it fails, I have not already submitted/published an edition. The edition is not a big deal, but if the deployment is canceled and the files were submitted, then deploying later is a difficult task. We had to do this once, customer wanted LSCS/LSDS deployment from editions. The corner cases were a nightmare