Website deployment options and patterns

[monohusche]

Hi there,

we have built our B2C website on top of Adobe CQ5 and based on the REST paradigm where java script code is executed in the browser making subsequent calls to our service backends. 

We are facing a couple of issues and I was wondering whether anyone can provide some insight regarding standard patterns to solve these (disclosure: I am not a CQ5 expert, so don't hesitate to point out obvious CQ5 "no brainer" solutions)

1. Based on our highly manual and holistic/coarse grained deployment processes, the confidence that it will actually work in production is quite low. Hence the business would like to verify the production deployment before releasing it to the public. What would be the pattern to establish an environment which at the same time can provide different versions of the same artefacts without necessarily duplicating the whole environment ? This would also be applicable to generic multivariate testing (I am not talking about the OOTB multivariate testing tool (focused on banners) that CQ5 provides.

2. The second topic which is actually quite related is the ability to provide rolling updates (i.e. no planned downtime) and the implications for the different layers (author, publish, static pre-rendered content on web servers, CDN updates)

thx a lot,

Nick

[smacdonald2008]

I highly recommend that you spend time reading through the wealth of AEM deployment/architecture documentation. There is a lot of documentation that will answer your questions. Start by reading through these topics:

http://dev.day.com/docs/en/cq/current.html#Deploying Adobe Experience Manager

 For information about rolling updates -- see: http://dev.day.com/docs/en/cq/current/administering/multi_site_manager.html.

HTH

[monohusche]

Thanks for the response,

I have read quite a bit about CQ5, and I am aware of the LiveCopy concept and the ability to automatically synchronise parts of the website. I did see this feature though primarily as a means to manage multilingual content with losing the structural consistency.

This is also the key use case described in the MSM article.

Hence my question as I couldn't find the scenario that I described anywhere within the Adobe CQ5 documentation.But it certainly looks like a good direction even though the Blueprint concept introduces some constraints regarding the required structure (i.e. the first child layer below the root have to be the language folders).

thx Nick

[Ojjis · Accepted solution]

Hi Nick.
1) I bet there are a few ways to go here. One thought on this would be to have a separate test environment in which you could test different versions of your bundled code. This could then be managed in the OSGi console. You can read more about this here http://dev.day.com/docs/en/cq/5-4/deploying/configuring_osgi.html

2) Rolling updates in a normal scenario are all there OOB. The OSGi nature of CQ/AEM has this as it's strength and you will apply updates of both code and content on the fly if you wish without any downtime. You simply install the new code on the fly.

One example could be as follows:

1. The author servers will get updated with the new code eg. via a maven build deploy (no downtime needed)
2. The new code/bundle will then later be published from the author environment (eg. via the package manager)  to the publishers involved. You can also update the content straight away from the authors like pages, assets etc (still no need to stop any servers).
3. If you want to do some cleaning up on the cache/dispatcher layer it is possible to do so without any downtime as well. Apart from that this layer would not be affected at all.

Also there are a lot of options when you set up your physical environments. Lets say that you have several author servers with several publishers and dispatchers on that. Then you can provide different legs to your site and those can be taken down independently for server maintenance and updates of the product itself without affecting the uptime of the site. There is a lot of articles about how to set this up as well in the KB.

Maybe you knew about most of these things but I hope you will get some ideas.

Good Luck
/Johan

[monohusche]

Thx Johan, much appreciated.

I am aware of the underlying OSGi framework as well as the Author-Publish-Dispatcher concept (incl. cache flushing and integration with external CDN's).

Still our requirement is slightly different (maybe I used the wrong terminology) as in our business users don't "trust" that existing test environments are consistent with the production. Therefore, they would like to verify that everything has been deployed properly before allowing external customers to access the updated assets. As we want to reduce downtime, that ultimately means that we need to provide two versions of the same page (and therefore potentially different backend logic) at the same time.

Which means that different versions of the same component/asset/page need to have different unique identifiers, and so far, the MSM seems to be the way to go to make such variantions happen. Just not sure whether this is a valid use case of MSM as it hasn't been mentioned anywhere.

thx Nick