After some discussion following the HubCR description in the previous post I thought it would be nice to describe more useful ways of deploying Z2 with some pros and cons. After all, that’s good input to next version’s documentation anyway (note to myself: Add as Wiki content).
Let’s get started with THE standard out-of-the-box of operating Z2: All Z2 homes connect directly to an SCM (Subversion or Git) and nothing else is ever needed:
For development setups there is no better choice: Everything is intrinsically as up-to-date as possible and necessarily self-contained. Also for production setups (in that case the SCMs represent a production branch) this is great, if you do not worry about having source code being downloaded to production machines (a consequence of the local compilation step). It’s great for essentially the same reasons the development setup is cool: Minimal infrastructure required, no inconsistencies, simple scale-out, complete change history.
When deployments get bigger or you are worried about source code on production machines, the Hub Component Repository (HubCR) provides another level of scale and isolation without violating the pull-deployment approach. The HubCR looks like the regular component repository abstraction to reading nodes:
It prepares a pre-compiled view that does not contain source code anymore. Also it removes the need of compilation on production machines (which is actually not a big deal, as that would happen in parallel anyway). More significantly it takes away load from the SCMs. Should the HubCR nodes eventually become a bottle neck, these could be clustered as well. (Clustering of HubCR is not available today!).
The price to pay in comparison with the development setup is that a change will not be rolled out to the production environment before the HubCR node has been synchronized. And of course, you need to maintain a HubCR node in the first place.
A future application of the HubCR is to support automated updates for remotely hosted on-premise solutions. The hub side would provide the updates to remote systems and enforce licenses.
But now, let’s leave the pull-deployment approaches aside and see, if we can find some good reasons for push-deployments.
If your execution environment is far away and connectivity is poor or cannot be guaranteed at all and you still want to make sure there is no source code on production machines, you may create a binary export using the Distribution Exporter tool.
That tool creates a source code free repository structure that is semantically equivalent to the original source repositories (as seen from Z2) – much like the HubCR does it – but copies the results into a folder structure that can be used to create another repository.
In the case below, this is yet another SCM, that has production system configuration (which typically differs from development configuration):
Turning the arrow has non-trivial implications (i.e. you need to push and delta computation is not trivial). However as there is a version-controlled store that holds the production config, you still have good control over who changed what and when. In contrast to the HubCR, the repository can be hosted elsewhere – so that network access is not required or does not need to perform particularly well.
The last case to look at is – once more – very different from the others. Suppose you want to ship your solution in a simple bundle that can be installed into a remote file system.
In that case, you would use the Distribution Exporter tool and bundle the result as a file system component repository with a Z2 core that references it.
This is the closest to a traditional deployment and can easily be implemented via a build script.
z the world 