z2-Environment

h1. Frequently Asked Questions

{{toc}}

h2. General questions

h3. What is z2 not?

The z2-environment is not a make tool like ant or maven. It's not a replacement for JEE servlets or other JEE techniques. It's not a Spring competitor. And it's not a new way to write software like aspect orientated programming.

h3. So what is z2?

The z2-environment can be seen as an extension to a common JEE server (like Jetty in our case) that enables the server to retrieve sources directly from the [[Glossary#SCM|SCM]], compiles them on demand and restarts modules that have been changed (plus the depending modules). A key point of traditional developing and running web applications is _pushing_ deployables to the server. Z2 turns this around and _pulls_ the sources by itself, bypassing all kinds of make/build infrastructure and deplyoment processings.

h3. What's the difference between _push_ and _pull_?

In a traditional _pushing-environemnt_ the source code is compiled, assembled and packaged into deployable units. These units are activly deployed (i.e. pushed) to the server. 

In opposite to this the _pulling-environment_ doesn't need the package assembly steps. It just needs the trigger to "synchronize itself with the source repository". Now all changed sources can be easily determined (using the history feature of the [[Glossary#SCM|SCM]]), downloaded and compiled. Then all modules that are affected of the changes are dropped and restarted (this works simalar to the hot-deploy mechanisms provided by modern web containers).

h3. What are the drwbacks of the _push_-approach?

Often the deployment of one artefact A requires the deployment of some artefacts B and C containing features required by A. Unfortunately the newest version of B also might need some changes provided by D and so one. The first problem is determine the transitive hull of all deployment units that one has to push onto the server. Once you found all deployables you might recognize that 90% of the changes you are about to deploy have nothing to do with the small feature that you are going to activate. Furthermore most of the deployables are not developed or maintained by you but by someone else. They might be a result of a nightly build or might be the result of a manually built. That means in order to activate your small feature you have to bring your system into a undefined state, you cannot tell what "version" your server has. The propability that the set of deployables contain one or more bugs is increasing with the number of deploy units and the burden of proof is on you to localize the bugs.

One thing you can observe is that developers start to isolate their systems against each other. They try to postpone updates from other colleagues or teams as long as possible. In the worest case everyone is working on a different solution. As a result the re-integration pain (that is the process of getting everyone on the same level again) can be tremendous.

Another problem with the push-approach occurs when updating large systems. You have to push _all_ deployables to _all_ machines.

All these problems above can be solved or improved using continuous integration tools like "Hudson":http://hudson-ci.org/ or distributed configuration management tools like "Puppet":http://puppetlabs.com. Even if these are great tools they can only ease the pain but they cannot solve the root problem which lies in the _push_-approach.

h3. What are the benefits of the _pull_-approach?

In a _pulling_-environment the source repositories become an integral component of the system. The runtime _knows_ the source code and has direct access to it. This requires that the source code has a certain structure so that the runtime can identify modules, web applications libraries, configuration files etc. But this usually the case, because almost the same requirement is true when you work with IDEs like "Eclipse":http://www.eclipse.org.

In order to activate your latest changes you have to simply trigger a _synchronization_. That means your system will look up the source code repository and identifies _all(!)_ sources that have been changed by you and your colleagues since your previous sync. As a result all development systems are always on the same state and the state stored in the repository. Integration happens on a daily or even hourly base which leads to very small integration pains. There is no need for a make environment but all systems are automatically continuosly integrated! 

Updating large systems means to bring the changes into the attached source repository and tell every instance to run a synchronization. The overall synchronization cycle can be done in an iterative way so that in every iteration only a few servers are synchronized. 

h3. Can this work at all?

A good example that compilation on the server works pretty well are JSPs. You could write your web application using plain JSPs and you can already enjoy the luxary of compile on demand.

h2. Installation

h3. How do I install the z2-environment

One of the basic z2 paradigms is: "Don't install, just copy and run". The big benefit of a system-centric approach like z2 is, that the configuration is part of the system; it's like the source code (and there are good reasons to put configuration into code sometimes). The [[Glossary#SCM|SCM]] should contain everything to get your system up a running. You got a new team member? "Copy" the system and start it. You have to scale out your productive site? Just copy the system to the new nodes and start them. "Copy" here means either "do a SVN checkout" or a "Git clone". The advantage over a plain copy is, that you can easily update or system with a simple "svn update" or "git pull".

h3. How do I run the z2-environment for development purposes?

h3. How do I run the z2-environment for productive purposes?