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; } } }

Workflow process for Editions

krasteleva

Hi everyone,
I have very specific workflow requirements from the client, and I am not sure how we can make it work for Interwoven. This is what we have:

CPO – main project branch
/CPO/prod/ - branch to manage daily updates
/CPO/prod/work – only one workarea in this branch

1. Development and 1st step of review happens in /prod/work – workarea
2. Final sign-off MUST happen only after an edition is created.
2.1 After 1st step of approval content is submitted to staging, new edition is created
2.2 This edition is deployed to QA web-server (this is web-server with OpenDeploy receiver on it) for review by QA team
2.3 QA team approves to the edition
2.4 Edition is deployed to PROD web-server

My main question: is it a right approach to use editions for QA step?
What happen if edition is rejected by QA team?
Can we do any reject/approve activities after the content is submitted to staging?

Many thanks!!
Irina

Find more posts tagged with

Comments

Pawan

Ideally, whatever goes to QA server for review/approval, the same should go to Prod server too.
Creating and deploying an edition each time depends on how much content is developed and reviewed each time. If its just 2-3 files then you can just submit and deploy them without making an edition. By doing this you make the workflow process faster.
In case the QA rejects the current deployed edition, can I assume the current edition is left on the QA web-server in confirmation that the changes will be deployed soon? so, you can leave the current edition as is. However, if you could delete the edition on rejection, then you can save yourself from any any future revert confusion

ISCBorisB

krasteleva

Thanks a lot for your response, it’s very helpful!

And yes, you have a good point about approve/reject functionality. Even after we run the task that submits files to staging and creates edition, we can have a task in workflow that sends the files to review by QA team.

In case of reject we definitely go with Scenario 1.
My concert is that once edition is rejected we will have “bad” (rejected) files hanging in the staging area of the /prod branch. We cannot create a new edition until the “bad” files are fixed. All other “good” and ready to go live files will be stack in the staging area until the “bad” file is fixed.

Is there are any work around, any good solution for this scenario?

Thank you!!
Irina

Pawan

As Bo already mentioned in his scenario 2, upon rejection you can deploy your previous good edition back to QA server, so its in sync with the the prod server, thats what you want, right?

ISCBorisB

Thanks a lot for your response, it’s very helpful!

And yes, you have a good point about approve/reject functionality. Even after we run the task that submits files to staging and creates edition, we can have a task in workflow that sends the files to review by QA team.

In case of reject we definitely go with Scenario 1.
My concert is that once edition is rejected we will have “bad” (rejected) files hanging in the staging area of the /prod branch. We cannot create a new edition until the “bad” files are fixed. All other “good” and ready to go live files will be stack in the staging area until the “bad” file is fixed.

Is there are any work around, any good solution for this scenario?

Thank you!!
Irina

There are several ways, none of them very good though.

For example, you can restore prior Versions of the rejected Collection in some WA and Submit them thus creating
a *Clean* Staging for the usual "Publish / Deploy to QA" Procedure. Disadvantage of the method is that you would
have to maintain "bad" Assets modifications somewhere, deficient as they are. Depending on how exactly you do that there
may be additional WA updates, you may have to deliberately create/resolve modification Conflicts, etc.

Alternatively, you may create dedicated "Selective Deployment" Workflow using FileList Deployment mode. With this,
an Edition stays as it is (eg rejected) but you can select / deploy arbitrary subset of Files from it. Disadvantage
is that your Edition no longer reflects QA Environment state, kinda defeats the whole purpose of Publishing it in
the first place.

There are other options, like introducing a concept of "Release" that may or may not correspond to the Edition, etc.
No matter what you do in that respect, try to keep it simple and short-term. Remember, the best way to fix the problem
is not to create it in the first place

krasteleva

There are several ways, none of them very good though.

For example, you can restore prior Versions of the rejected Collection in some WA and Submit them thus creating
a *Clean* Staging for the usual "Publish / Deploy to QA" Procedure. Disadvantage of the method is that you would
have to maintain "bad" Assets modifications somewhere, deficient as they are. Depending on how exactly you do that there
may be additional WA updates, you may have to deliberately create/resolve modification Conflicts, etc.

Alternatively, you may create dedicated "Selective Deployment" Workflow using FileList Deployment mode. With this,
an Edition stays as it is (eg rejected) but you can select / deploy arbitrary subset of Files from it. Disadvantage
is that your Edition no longer reflects QA Environment state, kinda defeats the whole purpose of Publishing it in
the first place.

There are other options, like introducing a concept of "Release" that may or may not correspond to the Edition, etc.
No matter what you do in that respect, try to keep it simple and short-term. Remember, the best way to fix the problem
is not to create it in the first place

Exactly my point!! I don't want to create extra problems and want to offer client a good and clean solution in a first place. To do that should I simply say that all review/approval has to happen in workarea, and contect is submitted to staging (+edition is created) only after the fignal sign-off ? Is this a right approach?

Thank you!!!

krasteleva

As Bo already mentioned in his scenario 2, upon rejection you can deploy your previous good edition back to QA server, so its in sync with the the prod server, thats what you want, right?

Correct we can use previous editions for QA server.

But my concern is that we won't be able to create new editions until the error in staging is fixed. All other 10 editors will be sitting and waiting until the "bad" file is fixed. They can submit new changes to staging, but we cannot cut new edition and deploy it because of the "bad" file.

Pawan

1. Development and 1st step of review happens in /prod/work – workarea

I assume all Editors are working in this one and only workarea.

2. Final sign-off MUST happen only after an edition is created.
2.1 After 1st step of approval content is submitted to staging, new edition is created

This sign-off happens on the QA server and the Editors are still continuing their work in the workarea.

2.2 This edition is deployed to QA web-server (this is web-server with OpenDeploy receiver on it) for review by QA team
2.3 QA team approves to the edition
2.4 Edition is deployed to PROD web-server

Now, on rejection if you just want to create a new edition and deploy the corrected file(s) along with the previous correct file(s) to QA server, don't you expect the other Editors to stop their work? If the Editors keep working and submit their content the new edition is going to pick up that, however, you can either ask the Editors to just keep there updates in the workarea and not submit it untill signoff is obtained from QA.

I hope I understood your requirement correctly.

ISCBorisB

To do that should I simply say that all review/approval has to happen in workarea, and contect is submitted to staging (+edition is created) only after the fignal sign-off ? Is this a right approach?

Please note that there is no "One size fits all" perfectly good solution for every Business case. You are asking
questions that require detailed knowledge of your Project, Business requirements and the like. That said...

"Strictly Workarea" Review/Approval Procedure is not so much "wrong" as too restrictive. It may be used for example
by the small group on the same Subnet delivering static Pages like Intranet. In the Modern Enterprise infrastructure
multiple Pre-production Environments (QA, UAT, Staging, PreProd, __your_favorite_moniker_here__) are rather the norm.
There are many reasons for it, two most important are:

1. CMS often is only part of the picture. Web Applications must have some sort of rehearsal Environment(s) where it
all comes together, CMS Assets, Application Servers, Code, Data Feeds, FE GUI, Back-End Mainframes, you name it.

2. Organizational and Procedural requirements for the staged Reviews. Imagine QA, Usability, UAT, Business, Legal and
whatnot Approvals. This personnel does not need CMS access and does not want CMS access. You would not want it either,
it's an extra cost in Licensing, Training, Administration, Support, etc. All they need is a "Site" to play with.

Long story short, do not look for perfect solution. Find a good flexible one, deliver early, change (hopefully for
the better!) often and listen to your users

nipper

Long story short, do not look for perfect solution. Find a good flexible one, deliver early, change (hopefully for the better!) often and listen to your users

This is by far the best point in the thread. Long have I (I assume Bo, Fish, Greg, et al would concurr) tried to design the perfect solution when a simple yet flexible solution tends to work much better.

I have implemented the deploy to QA, reject, roll back QA, etc. Much more trouble than it is worth. 99% of the rejections are fixed immeadiately and resubmitted. Problem solved. The other 1 % ? Roll back changes, submit. That has happened to me once in all my implementations. Part of the problems developers have transitioning to architects is that we think like geeks, not content users. You think in the mode of writing the perfect solution, but it can get so complex and clumsy it is a waste of time.

me

krasteleva

This is by far the best point in the thread. Long have I (I assume Bo, Fish, Greg, et al would concurr) tried to design the perfect solution when a simple yet flexible solution tends to work much better.

I have implemented the deploy to QA, reject, roll back QA, etc. Much more trouble than it is worth. 99% of the rejections are fixed immeadiately and resubmitted. Problem solved. The other 1 % ? Roll back changes, submit. That has happened to me once in all my implementations. Part of the problems developers have transitioning to architects is that we think like geeks, not content users. You think in the mode of writing the perfect solution, but it can get so complex and clumsy it is a waste of time.

me

Thank you!!! This is extremely helpful conversation, and I received very useful advices from you.

“Simple, but flexible solution” will be my credo for this project. As you probably guessed already this is my first Interwoven application.

So here is the solution

1. Editors work in their workareas (the client requested me for a workarea per each of 10 users)
2. Initial review steps happens in workarea.
3. After that content is submitted to staging and deployed to QA server
4. External QA users will review the published content in QA server. (Boris was 100% right about Enterprise solution with external QA users…)
5. In case of rejection, for the first phase I won’t be building any complex solutions to roll-back staging. Editor can simply revert the changes in workarea and re-submit again
6. After the content is approved by QA team, Editor receives the notification and deploy the content to Prod server
7. Editions cut once a day for history/versioning purposes.

Sound simple and flexible enough?

Once again, thanks everyone, this is very helpful and very useful. You cannot learn things like that in TeamSite bootcamp, it comes with experience!!!

Irina

Adam Stoller

...
So here is the solution

1. Editors work in their workareas (the client requested me for a workarea per each of 10 users)
...

I'd push back on that if you can.

Multiple workareas per branch is generally going to lead to problems. (one workarea being out of sync with another workarea, conflicts, merges, etc.)

I'm not saying it can't work - but if you can avoid it, it tends to keep things simpler. Note that one-for-ten is not really that different from one-for-all; if they want separate workareas, it should either be based on per-user or per-some-other-functional-aspect like one-per-project, one-per-team, etc. Using an arbitrary number doesn't really mean anything other than that someone is going to have to spend a lot of time maintaining group memberships to limit users to the workareas to which they have been assigned.