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 © ZFabrik Software KG 2010

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! © ZFabrik Software KG 2010

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. © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

Scenarios... © ZFabrik Software KG 2010

<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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

Positioning... … w.r.t. to ANT and Maven © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

The “classical” approach 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 What are the sources of © ZFabrik Software KG 2010 what you are debugging (but others change)? what you are debugging (but others change)?

The “classical” approach  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. © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 What are the sources of © ZFabrik Software KG 2010 care extreme debug what you are debugging (but others change)? what you are debugging (but others change)?

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. © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

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 © ZFabrik Software KG 2010

http://www.z2-environment.eu	184
http://localhost	5
http://www.slideshare.net	1
http://www.zfabrik.de	1

1006 Z2 Intro Complete

by gnomie on Aug 03, 2010

Accessibility

Upload Details

Usage Rights

4 Embeds 191

Statistics

1006 Z2 Intro Complete — Presentation Transcript