Best practices in Parallel Development

Quick_Learner

Hi,

I'm looking for suggestions to the below situation I have in a parallel development environment in Teamsite:

Current Env:

- I have a Teamsite Environment with two branches "DEV" and "PROD"

- In "DEV", we have multiple workareas to facilitate parallel development

- In "PROD" we have just one workarea

- "DEV" deploys files to the development environment (front end)

- "PROD" deploys files to both Pre-Production and Production environments (front end)

- Content moves from "DEV" to "PROD" branch through workflow

Problems:

- We cannot create Editions because multiple changes to a single file can be present in "PROD" at the same time

- In case of reverting deployments, we will have to do each file independently

- There is no back up of PROD content in case the front end production server crashes out

Possible solutions: Here are the solutions I'm thinking for now.

- Introduce two new metadata fields "prod deployed date" and "pre-prod deployed date". The dates will at least help us identify which version of the file is in Pre-prod and prod

- Create a new branch out of "PROD" and make this the branch that will always have one-one mapping with PROD. So, only those files that are ready to go to PROD will be in this new branch. And this will also facilitate the creation of Editions

Is there anything else that can be done to better the solutions? Or anything that I'm missing to complete the solution? Please let me know.

Thanks,

Chanti

Find more posts tagged with

Comments

nipper

Keep it simple.

You do not mention if you are working with SP/LS but I assume you are not. I also assume this is content not code.

Most people moved away from mulitple workareas as well as deploying from editions. What works for code doesn't always work for content.

The problem you have pointed out is that you never really know what is out in production at any given time. I assume review are done on Pre prod as that is the only true prod like instance you have.

Another issue with configurations like this is that (depending on implementation) if you have multiple workflows active at once, it can cause inconsistencies in the review environment. Often you have to check for existing WFs first.

Rick Poulin

To add to Andy's point, this is partially what STAGING is for. The STAGING in your prod branch should be an identical match what is live on your production runtime. Your pre-prod deployment from this branch should simply not submit the files at the end of the workflow because the content is still "work in progress".

Quick_Learner

Thanks Andy and rpoulin for quick responses.

Yes, we are not using SP/LS. And yes, most of the deployments are content deployments. We also have few aspx files and some dlls but we can consider them as similar to content deployments itself.

And we do a great deal of communication to ensure/identify what content is in pre-prod. And we dont have a fool-proof way of knowing what exactly is in production

rpoulin,

I agree to your statement about STAGING. However, if we are configured for a parallel development, how can we separate the work of two users in "PROD" without submitting the change to STAGING? ex: user1 pushed a change to a file f1 from DEV to PROD. And the change is deployed to pre-prod. Now, user2 pushed another change (on top of the first change) on the same file f1, from DEV to PROD. Now, both changes combined, will get pushed to pre-prod. And now if I find out that change 2 (done by second user) is not required, how do I pull that alone in "PROD"? Also, if I just want to push the changes of User1 to production, how do I do that? Do I always need to bring it from "DEV" again?

Also, the current "PROD" is already in a bad state. So, do you think creating a new branch out of "PROD" will not help much? And if we stop submitting Work in Progress files to STAGING and submit them only when ready to go to production, will that help? And will both these options give same results?

Thanks,

Chanti

nipper

At this point, I would restrict the use of Prod branch to only things that are imminent for production. It only goes to the WA and then submit to Staging/deploy from Staging (or workarea) and cut an edition.

For the Dev branch let people push to Prod when they are ready.

You may want a 3rd branch called integration, for testing which should closely resemble Prod but I think that overkill.

Quick_Learner

So, as per what you are suggesting, I will have to use "DEV" to deploy to both development and pre-prod environments, right? And the content gets pushed to "PROD" after the content is approved in the pre-prod environment (there by, the content sits in the PROD WA until it is ready to be pushed to production.

Please let me know if I understood this right.

Thanks,

Chanti

nipper

Dev -> Prod WA (and pre-Prod) -> Approval -> Staging -> Production -> Edition

That way Staging is always what you have in Production. The Edition shows what it was in a time before.

Quick_Learner

Thanks a lot Andy. I just have one final question here. We will have situations where multiple changes need to be present in the same file in pre-prod enviornment (ex: changes from a project and change from a prod ticket). So, it will mean that the file in PROD WA has both the changes together. Now, at this point if the publishing manager approves the workflow for one of the changes, the file in WA gets submitted to STAGING. This will mean that both changes will go to STAGING. Is there a way how we can avoid this apart from co-ordinating to ensure that the file in PROD WA contains only prod-ready changes when the workflow is about to be approved? Also, in this scenario, we cant easily revert the file in PROD WA to contain only the prod ready change.

Thanks,

Chanti

nipper

You can fix that by only submitting to staging the filelist and not everything.

But then you have a configuration in Prod that was never tested because it is different from Pre Prod.

If this is a common requirement, then you need the integration branch and an instance of the application that can be used for integration.

It is *really* bad to push something out to production that was not tested in a lower environment. So Prod should *always* be based on what was tested in Pre Prod.

nipper

Also, I noticed that you said the same file will have changes that you only want some to go live. That is really hard to do and quite risky if you overcome the technical issues.

Are you talking a DLL/JAR?

Rick Poulin

Quick_Learner wrote:
Thanks a lot Andy. I just have one final question here. We will have situations where multiple changes need to be present in the same file in pre-prod enviornment (ex: changes from a project and change from a prod ticket). So, it will mean that the file in PROD WA has both the changes together. Now, at this point if the publishing manager approves the workflow for one of the changes, the file in WA gets submitted to STAGING. This will mean that both changes will go to STAGING. Is there a way how we can avoid this apart from co-ordinating to ensure that the file in PROD WA contains only prod-ready changes when the workflow is about to be approved? Also, in this scenario, we cant easily revert the file in PROD WA to contain only the prod ready change.

If your workflow is running in the PROD branch, then the person should be approving the combination of the changes.

If your workflow is running in the DEV branch, then the person is only approving one view of the changes but your submit should not affect the PROD branch. You'd need some secondary process to validate the merging of changes from different branches/areas.

If you put the solutioning aside for a moment, just think about these definitions:

PROD/WORKAREA = changes that are about to go live

PROD/STAGING = changes that ARE live (copy of the runtime)

If pre-prod is meant to be a reflection of what prod will be in the near future, then it should pretty much match PROD/WORKAREA and that's what your reviewers should be approving.

If pre-prod is meant to be some kind of sandbox where people can try things out and revert 5 times/day, then you should consider having as many pre-prod runtimes as you have DEV branches/areas.

Quick_Learner

Andy, rpoulin,

thanks a lot for your responses. I will need sometime to put this all together and be clear on what I should do. I'm sorry that I will not mark anything as solution for now. I will take one day to get back.

Thanks,

Chanti

Adam Stoller

I think the problem here is that the philosophy of what you're talking about is more applicable to code "change sets" than it is to content - which is why I think @nipper's & @rpoulin's comments seem to go round-and-round on the same subject.

Concurrent "development" generally doesn't apply to content (DCRs and static HTML files) - other than if one file references another (like for headers / footers / copyright info)

Concurrent development of code (be it PTs or something front-end specific) is more likely to be an issue, but one which should be dealt with on a DEV environment (both TeamSite and front-end) rather than trying to handle it within different branches on the same TeamSite server.

So - are you really talking about concurrent code development or concurrent content development? And if the latter, can you provide a more detailed example of how you see this coming about (i.e.: such that you would need to be able to approve n-of-m changes to a given file)?