1006 Z2 Intro Complete

2
The z Environment
- introduction -

© ZFabrik Software KG 2010

2
The z Environment is...

… the solution to humane life-cycle management for
Java solutions:
 Self-updating from source,
 Cost-effective and highly productive,
 Extremely easy to distribute,
 Transparent for developers and supporters,
 Auditable and versioned,
 Standards friendly and extensible


Motivation
 Operating a continuous integration infrastructure is
complex and costly
 Deployment of application servers and applications is
complex and time consuming - developers tend to
delay integration
 Operating developer build infrastructure is error-prone,
complex, and hard to debug

So Don't Do It!


Approach
 Runtime is fully capable of preparing all source code
and configuration for execution – no external toolset
required.
 Re-use of standard versioned store that holds
everything that defines a system's content – no
external configuration required.
 Store- and file system based integration with
development tools – no complex development tool
integration required.


Architecture: Deployment
Repository

 Many <home>s share one root
component repository - usually
implemented over a subversion
repository e.g. subversion,
a workspace,...
 Every <home> runs a <home> Check for updates
Java process that manages one or
more worker Java processes, as Machine
Machine
defined by a home layout <home> Machine

 Worker processes run whatever
manage
participates in their target states
 One <home> may run over several
component repositories, in
particular a dev repo that is defined Worker 1 Worker 2
over a workspace folder structure


Custom/Extensible Architecture: In-process

Programming Models
Servlet/JSP
OSGi Bundles

& Conventions
Applications

Jetty
Equinox

DB Migration SVN Repo
Migrate4j SVNKit
z2 implementation

Java Builder
Data Sources
ECJ
Component Model &
Component Factories
JNDI Naming
Kernel (binary)

Timer/Jobs
Resource Management
Worker Processes
System States
JRE


2
Components in z
Components
Repository as defined in
 The component concept captures
anything stored in the repositories the repo
that z2 understands at runtime, for C1 C2
example e.g. Java e.g. a data
source
 Web Applications
Cn
 Worker process configurations
e.g. a Web App
 Java modules o nds
corresp
 System states
 At runtime, in particular during Worker Process
Web resource in
Web resource in
development, changes in the Web App WebContent folder of Cn
WebContent folder of Cn

depends
repositories translate to component Cn
C1
Java Classes
Source files read
state invalidations (e.g. unloading C1 Source files read
from C1 and compiled
from C1 and compiled
JDBC connection pool
of a Web application) C2

Connection props
Connection props
read from C2
read from C2


Synchronization is about letting go...
Components
Repository as defined in
 When synchronizing, changes in
the repository (since the last the repo
synchronization) are detected and 1
C1 C2
translated into component
e.g. Java e.g. a data
invalidations source

 Invalidations observe declared and Cn
implicit dependencies e.g. a Web App
Example: Detection
Example: Detection
 Invalidations are orchestrated by of modification triggers
of modification triggers
invalidation chain
invalidation chain
the <home> process, so that the
life-cycle of worker processes is 2 Worker Process
also subject to change detection Web App

depends
Cn
C1
 After invalidation, the <home> Java Classes

process will try to have all worker C1
3
JDBC connection pool
processes attain their target states C1

again


System States state
Example: Travelhands
Example: Travelhands
environment/up state graph
state graph
 System states abstract operational participates
modes of a system into
configuration objects
state

es

de
Examples are:

pe
t


ipa
de.travelhands/up

nd
tic

s
de.travelhands/up

par


→ Start everything needed for participates
the Travelhands front end state state

de.travelhands/up_db
 environment/jobWorkerUp de.travelhands/up_dev

→ target state for batch jobs participates
participates
 Components (in particular system
states) can participate in states
and depend on states: “run” before web schema

attaining a state, or a state must be de.travelhands.app/web de.travelhands/tenantDB
attained before the component web

“runs” resp. de.travelhands.admin/web_tests


Scenarios...


<home>* Installation and Operation
Checked in
Checked in
 Best practice: Keep bootstrapping core dist
core dist
core distribution in same repository (~7 MB)
(~7 MB)
as the base system
 Install and update <home> by
issuing simple Subversion client svn co …
svn co …
svn up ...
svn up ...
commands
 Core installation is a matter of
seconds
 All further configuration is stored in
Subversion and loaded on-demand
 As all configuration and code is in
a versioned store, configuration
changes are tracked, secured and
can be reverted at any time. <home> 1 <home> 2 <home> 3


Development & Modification Source
repo
 Have a running local <home> for
t
testing and provisioning of binary ou
ec
k A
 Check out projects (say A) to ch
modify from the Subversion repo
into an Eclipse Workspace
sync all
 Use the Eclipsoid plugin to “arm” but A from
those projects and to satisfy all here
project dependencies
 Keep modifying, sync, and test
until done.
 Note: There is no deployment A' sync A
from here
 Commit or revert changes
Project in <home>
 “Disarm” projects. Done Eclipse
workspace


System Creation and Cloning
branch

 A system is completely defined
(incl. configuration) by a repository
URL (and hence a repository)
 New systems are created by basic
repository operations (e.g. branch) SCM
 When cloning, only essential
interfaces with the outer world, e.g. OR copy
database URLs, must be adapted
 Every system constitutes a
complete development branch
 Updates are promoted between
repositories via Transports
SCM SCM
 Shipping means to deliver a
repository dump


Transport
 Transports work via tool-supported
creation of delta-workspaces that prepare
allow reviewing of changes before
committing to the transport target

review
(in particular when considering
configuration)
commit
 Transports promote changes
between repositories (and hence prepare
systems)
 A standard transport route is

review
helpful but not restrictive: cross-
transport are a necessary reality
commit
 Transports can be used for remote
upgrades as well


Support
Support Production

 As the runtime is a faithful
representation of its repository,
there is generally no doubt about
check
sources when debugging
 Since adding another <home> is debug,
trivial, debugging without emergency fix
Part of
interfering with production runtimes system
is easily achieved
 As every system is a potential
development branch, emergency
fixes can be applied on the spot
 In general: Fixes can be supplied
as unified diffs


Support Workflows
Traditional bug fixing flow: Bug fixing flow with z2:
1. Analyze the bug report: What release? 1. Analyze the bug report: What system?
2. Identify patch level of product or module 2. Install local <home> for that system,
possibly on site
3. Find code line for that release
3. Debug and fix on local <home>
4. Verify/Install suitable app server
4. Test fix. Submit fix. Transport fix or provide
5. Build application for given version (e.g. tag) diff
6. Deploy application 5. Customer imports fix and tests again
7. Debug, apply fix and test 6. Propagate fix to other releases via
transport
8. Submit and build application again
9. Copy binaries to customer – hope that it
does not contains lots of other changes
10. Convince customer to install new
application and test


Positioning...

… w.r.t. to ANT and Maven


In Principle...

Dev, QA, or Prod. Runtime
Sources

Define what's
happening there

M ,
od bug
ify de
t, t
es por
T p
su

Developers


So, Where is the Problem?
 Java application servers do not live on sources
but rather on binaries
 It is up to the development organization to
(somehow) provide those binaries and hence...
 … find out what binaries are affected by a change
 … find out what binaries belong to one solution
 … keep development environments up-to-date
 … integrate changes (continuously)
 … live with delays between commit and run


The “classical” approach
Sources
Nightly build

QA. Runtime
(everything?)
deploy/push
(everything?)

Deployables
commit changes
Check out and

central

Dev. Runtime
local
Dev build
(what?) deploy/push
(workspace)
Developers

(what?)

Deployables

debug


Sources
Nightly build

QA. Runtime
(everything?)
deploy/push
(everything?)

Deployables

How “hard” is it to
How “hard” is it to How “equal” are these?
How “equal” are these?
commit changes
Check out and

introduce a
introduce a
structural change?
structural change? How “hard” is it to get this
How “hard” is it to get this
central up to date?
up to date?

Dev. Runtime
local
Dev build
(what?) deploy/push
(workspace)
Developers

(what?)

Deployables

debug
What are the sources of
© ZFabrik Software KG 2010 what you are debugging (but others change)?
what you are debugging (but others change)?

 Ok for monolithic projects
(only few deployables)
 Breaks for modular systems
(too complex to keep in sync: Due to the “push” approach,
it's up to the developer to keep things straight)
 Breaks for large projects
(turn around times too long)
 Summary: Simple but doesn't scale.


The Maven Way
Sources

QA. Runtime
Continuous
depoy
Integration
deploy/push

h
p us
SNAPSHOT Repo

loy/
dep
commit changes
Check out and

central e
Release Repo
as

Dev. Runtime
e

local
rel
(workspace)
Developers

sh
u
/p
oy
Dev Build

pl
de
(mvn) Deployables

debug

Who maintains
The Maven Way
Who maintains
all this
all this
infrastructure?
infrastructure?
Sources

QA. Runtime
Continuous
depoy
Integration
deploy/push

h
p us
SNAPSHOT Repo

loy/
How hard is it to
How hard is it to How “equal” are these?
How “equal” are these?

dep
keep the
keep the
commit changes
Check out and

dependency
dependency
version vector right?
version vector right? How “hard” is it to get this
How “hard” is it to get this
central up to date?
up to date?
e
Release Repo
as

Dev. Runtime
e

local
rel
(workspace)
Developers

ush
/p
oy
Dev Build

pl
de
(mvn) Deployables
binary release
binary release
management requires
management requires
extreme care What are the sources of
© ZFabrik Software KG 2010 care
extreme debug

The Maven Way
 Maven is built around versioning, versioned
dependency and release processes for binaries
 It does not address the system consistency
side of things
 It is geared towards a distributed, independent
community of producers of libraries
 It does not care about source consistency
 Summary: Useful for the community, much less
interesting for solution providers.

2
And in z
Sources

QA. Runtime
Pull what has changed
since the last pull

Pull
sinc what h
commit changes
Check out and

e th a
e la s chan
st p
ull ged
central

Dev. Runtime
Pull from workspace with prio
(workspace)
Developers

Debug


2
In z
 A runtime that updates itself on-demand,
according to changes in source repositories
 Developer runtime takes developer workspace
into account with preference
 The runtime is a faithful representation of the
repository – no question where sources are.
 Almost like a scripting environment


Outlook
What could be done but we did not need to so far:
1. z2 as life-cycle tool over any Java EE server:
 z2 manages update checking and invalidations
 Instead of start/stop perform deploy/undeploy
2. Component Repository over Maven Repository
 Integration of existing assets
2
3. z for PHP et al
 Consistent dev and production environment


More Information
Try it out at:
www.z2-environment.de

Contact us at:
contact@zfabrik.de


1006 Z2 Intro Complete

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (20)

Similar to 1006 Z2 Intro Complete

Similar to 1006 Z2 Intro Complete (20)

1006 Z2 Intro Complete