vineri, martie 30, 2007

Releases in Maven

Procesul de release al proiectelor Java este total dependent de uneltele folosite. In cazul nostru de Maven. In primul rand trebuie sa clarificam cateva aspecte legate de Maven cum ar fi repository-uri si snapshot-uri. Apoi vom vorbi despre release-uri.

Repository-uri in Maven

Prin repository se intelege locul in care sunt depozitate/accesate artefactele, structurate pe grupe si versiuni (reprezinta de fapt un simplu director intr-un file system). Acestea sunt de mai multe feluri:


  • Local – este in structura de fisiere, implicit: USERHOME/.m2/repo; de aici sunt fosite in procesul de compilare (implicit compile) sau folosite in impachetare (runtime)
  • Remoute – un repository aflat in afara masinii locale - extern
    • intern – un repository in interiorul organizatie care poate fi deservit via http, ftp, file; prin intermediul acestui repository se partajeaza artefactele intre membrii echipei care lucreaza la proiect; a se intelege repository-ul unei companii
    • central – repository-ul central; in speta maven2.org

Deployment – procesul de stocare a artefactelor intr-un repository intern; artefactul poate fi astfel partajat de membrii echipei (echipelor) care dezvolta; se realizeaza prin mvn deloy.

Pentru deployere trebuie sa specificam locatia prin intermediul unei intrari distributionMnagement in POM-ul aplicatiei; deployerea se poate realize prin urmatoarele protocoale: file, SSH2, SFTP, FTP, SSH. Protocolul HTTP poate fi folosit doar pentru accesare.

A se face distinctie fata de deploymentul in serverul de aplicatii. Acest lucru se realizeaza prin accesarea unui task ant de copiere sau prin intermediul unui plugin de genul jboss-maven-plugin.

Instalare - install – procesul de stocare a artefactelor in repository-ul local; printr-o astfel de instalare artefactul devine dependenta accesibila celorlalte proiecte din local; se realizeaza prin mvn install.

SNAPSHOT-uri in Maven

Un aspect foarte interesant al utilizarii Maven este modul de lucru colaborativ la un proiect in interiorul unei organizatii avand mai multe module dezvoltate de developeri sau echipe diferite (un alt caz ar fi cel in care intreg proiectul la care lucreaza echipa are o dependenta de un alt proiect dezvoltat de o alta echipa).

Acest lucru presupune accesul rapid la artefactele produse de altii. O solutie simpla ar fi partajarea surselor via SCM (CVS sau SVN) de toate echipele si de toti dezvoltatorii. Acest lucru impune update de surse in local (impreuna cu POM-urile aferente) si build in local de catre fiecare developer, lucru care determina aceleasi artefacte generate pentru toti utilizatorii in repository-urile lor locale.

O alta solutie ar fi partajarea artefactelor via repository-ului intern al organizatiei. Acest lucru presupune deployment de artefacte. Aceasta este optiunea pe care Maven o prefera pentru lucrul colaborativ. Aici intervine notiunea de SNAPSHOT.

In Maven starea unui artefact in timpul dezvoltarii este cel de SNAPSHOT. Procesul de dezvoltare implica modificari frecvente ale surselor care dau artefactului o stare de instabilitate – cuprinde functionalitati care nu sunt clar specificate. Pentru a avea acces la ultima versiune a unui artefact inainte de a fi releasat, chiar cand el este in proces de dezvoltare, putem sa punem in POM-ul nostru o dependenta de tip SNAPSHOT. Un exemplu ar putea fi urmatorul:


<dependency>
<groupId>springframework</groupId>
<artifactId>spring</artifactId>
<version>1.2-SNAPSHOT</version>
</dependency>


Artefactele de tip SNAPSHOT sunt deployate intr-un repository intern pentru a fi usor accesibile celorlalti pe partcursul devoltarii (manual de unul din developeri sau autoamt de serverul de integrare continua). Prin procesul de deployere, artefactul de tip SNAPSHOT capata versiuni de genul 1.0-20070521.121124-1 (versiune majora.versine minora- timestamp-build). La fiecare noua deployere se schimba timestamp-ul si se incremeneteaza build-ul.

Pentru deployere se specifica un repository de SNAPSHOT-uri in POM (deployerea se va face prin protocolul file):


<distributionManagement>
<snapshotRepository>
<id>internal.snapshots</id>
<url>file://localhost/c:/repository/snapshots</url>
</snapshotRepository>
</distributionManagement>


Spre deosebire de release-uri, dependentele de tip SNAPSHOT ale proiectului sunt aduse in repository-ul local din repostory-ul intern de fiecare data cand se face build de proiect (chiar ultimul daca se prtecizeaza –U, altfel ultim in ordin de o zi). Se poate specifica explicit o politica de update de intr-un tag de forma updatePolicy. Un repozitory intern de artefacte de tip SNAPSHOT se precizeaza astfel in POM:

<repository>
<id>internal.snapshots</id>
<url>file://localhost/c:/repository/snapshots</url>
<snapshots>
<updatePolicy>interval:60</updatePolicy>
</snapshots>
</repository>


Pentru a evita deployment-ul manual de snapshot-uri se poate opta pentru a delega acest proces serverului de integrare (Continuum sau oricare altul). Acesta va deploya in favoarea noastra ultimele SNAPSHOT-uri de pe SCM intr-o locatie aleasa, in principiu in repository-ul intern de SNAPSHOT-uri.

Release-uri in Maven

Release-ul unui proiect in Maven se obtine prin intermediul unui plugin special numit maven-reelase-plugin. Acesta permite automatizarea procesului de release.


Daca nu e instalat in local trebuie instalat. O solutie check-out din repository-ul lui si mai apoi mvn install.

Pentru a crea un release trebuie indeplinite urmatoarele conditii :

  • proiectul trebuie sa aiba versiunea **-SNAPSHOT; si celelate submodule trebuie sa fie la fel
  • nu trebuie sa aiba dependente de alte artifacte sau plugin-uri care sunt **-SNAPSHOT; ca o solutie se va crea dependenta de versiunea care nu e SNAPSHOT (chiar daca nu este in POM)

Pasii necesari sunt urmatorii:

1. daca nu e implicit stabilit, se poate specifica locatia in SVN unde se va pune tag-ul creat:


org.apache.maven.plugins
maven-release-plugin

2. se apeleaza

# mvn release:prepare -DdryRun=truemvn
# release:cleanmvn release:prepare
  • prepare = pentru a pregati releas-ul - inseamna creare de tag in SVN, modificare de pom-uri
  • in cazul -DdryRun=true nici una dina ctivitatile prezentate nu vor fi comise efectiv (se creaza fisiere in care se reflecta modificarile)
  • in procesul de prepare se vor cere drept input versiunile - pentru tag si pentru viitoarea dezvoltare
  • cu release:clean se sterg aceste fisiere
  • cu release:prepare - se aplica schimbarile definitiv
  • in repository-ul local apar modificarile

3. se apeleaza

# mvn release:perform -DconnectionUrl=scm:svn:http://svn/repo/tags/1.1
# mvn release:perform
# mvn release:perform -DconnectionUrl=scm:svn:http://svn/repo/tags/1.1
-Dgoals="install"
  • pentru a face release la versiune - implicit deploy site-deploy
  • in mod usual se executa din director separat - ex prima linie (se va aduce de pe svn intr-un working directory unde se va face build, etc)

duminică, martie 25, 2007

Better builds with Maven

Este o mica carticica editata de Mergere . Nu stiu foarte clar statutul acestei firme si de ce ingrijesc ei aceasta carte, dar se pare ca ofera suport comercial pentru Maven (care ramane open source sub Apache). Un articol interesant (apropos de better)

Deosebirea esentiala intre Maven si Ant pare a fi urmatoarea: Ant poate fi deprins incetul cu incetul, exersand task cu task (sunt cateva idei de baza: task-uri, target-uri, proprietati, access pre file system, etc). Maven trebuie inteles in toata plinatatea sa pentru a fi intradevar util in dezvoltarea proiectului. Poti sa pornesti destul de usor la inceput dar ce urmeaza poate fi groaznic. Acest lucru poate fi desprins dintr-un interviu interesant despre Maven pe care il puteti asculta pe JavaPosse.

Ce incerc eu sa construiesc este automatizarea procesului de build pentru aplicatiile enterprise.

Pe langa Maven, din toate unelte enuntate in post-ul anterior am ales drept

  • SCM: subversion (mai la moda decat CVS, oferint acces via HTTP).
  • Server de integrare: Continuum ; nu sunt 100% convins asupra lui – pot sa schimb eventual cu Bamboo, Hudson, Luntbuild sau orice server de integrare care ofera supor pentru Maven 2 - o lista a lor o puteti gasi aici.
  • Maven Proxy: Artifactory

Problema principala pe care mi-am pus-o. Care este diferenta intre cei doi termini: build si release. Raspunsul nu l-am gasit usor.

Ca o precizare: am gasit 2 carti car se ocupa de automatizarea build-urilor:

  1. Pragmatic Project Automation – The Pragmatic Programmersautomatizare cu ANT, CVS, Cruise Control
  2. Accelerating and Automating the Build Process – IBM Press – automatizare cu ANT, Clear Case, Cruise Control

Dar nici o carte care sa cuprinda Maven, SVN, si alt server de integrare diferit de Cruise Control. Cruise Control este veteranul serverelor de integrare, cu fisier de configurare complex, dupa parerea mea invechit. Uneltele folosite au specificul lo rasa incat cele doua carti nu pot adduce lucruri practice ci doar aspecte generice despre build.

In a doua carte am gasit un raspuns interesant la intrebarile mele:

  • build si release nu sunt acelasi lucru
  • nu trebuie folosite ca verbe ci ca substantive – ele sunt un rezultat nu un process – putem vorbi doar despre un process care le genereaza

O definitie pentru build:

an operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product.

O impartire a build-urilor:

· Private Build - A build that is created by a developer in his or her own workspace. This type of build is usually created for the purpose of checking the ongoing status of the developer's changes, such as to assess whether his or her source code compiles.

· Integration Build - A build that is carried out by an assigned integrator or central function. This type of build can be performed manually by a lead developer or a member of the build team, or alternatively through an automatically scheduled program or service. This build is created to assess the effect of integrating a set of changes across a development team.

· Release Build - A build that is carried out by a central function, usually a member of the build team. This build is created with the express intention of being delivered to a customer, either internal or external. A release build is usually created in an isolated and controlled environment.

Definitia unui release:

...a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective.

Inseama ca un release este construit si folosit pentru a fi folosit de un third party – un client sau o echipa de testare (echipa de testare poate fi gandita ca un client intern).

Cum se reflecta toate acestea in uneltele alese deja (maven, svn, continuum)? Raspunsul in urmatorul post.

sâmbătă, martie 24, 2007

Uneltele de dezvoltare cu care am lucrat

Version Control

CVS

  • l-am folosit in firma (e vorba de CVS NT) dar nu l-am instalat niciodata

SVN(=Subversion)

  • l-am instalt cu Apache in fata (tutoriale)
  • il folosesc in mod curent

Perforce (comercial)

  • l-am instalat usor si e usor de folosit
  • nu tine directoare in local ca SVN si CVS ci numai pe server (nu murdareste directoarele locale)

Clienti si plugin-uri pentru Version control

Eclipse si Idea au integrare implicita cu CVS-ul. Integrare OK.

Subclipse

  • plugin pentru SVN pentru Eclipse detronat de Subversive

Subversive

  • cel mai bun plugin pentru Eclipse
  • folosit cu succes

Turtoise CVS

  • integrare in explorer-ul de Windows
  • l-am folosit doar pentru a aduce de pe net surse de proiecte

Turtoise SVN

  • integrare in explorerul de Windows
  • il folosesc in mod curent dar prea putin confortabil in operatiile de tip merge

Perforce are propriul client greu dar si ceva in stilul Turtoise. Are si plugin de Eclipse (Websphere de fapt)

Idea are in repository plugin pentru Subversion. OK.


Integration Servers

Cruise Control

  • e primul de acest fel folosit
  • Martin Fowler pare a fi avut un cuvant de spus

Bamboo (comercial - Atlassian)

  • se instaleaza usor
  • a mers din prima cu maven 2

Continuum (la Apache ca si Maven)

  • esecuri continue (probabil pentru ca incarc toata ierarhia de proiecte)

LuntBuild (exista si versiunea comerciala)

  • l-am folosit si l-am si instalat si merge
  • pare a avea o gestiune mai clara a versiunilor de build

Hudson

  • l-am instalat si l-am folosit fara success pentru Maven 2

Issue Trackers

Jira (comercial)

  • usor de instalat
  • o minune de aplicatie a la Atlassian – un design graphic foarte clar, inimitabil
  • integrabil cu Eclipse via plugin-ului Mylar (vi servicii web – SOAP si XML-RPC)

Track Studio (comercial)

  • l-am folosit in cadrul firmei dar nu l-am instalat
  • se pare ca ofera ceva suport si pentru managementul proiectului

Trac

  • unealta facuta in Pyton (parca)
  • l-am instalat local pentru teste dar l-am folosit pe net (support oferit gratuit)
  • design superb dar nu l-am folosit in productie

Build Tools

Ant

  • target-uri care incapsuleaza task-uri deja implemnetate
  • task-uri pentru operarii de baza deja scrise; diverse librarii si unelte ofera si task-uri de ant
  • orientat pe actiuni

Maven

  • orientat pe metadate despre proiect
  • cicluri de viata predefinite
  • system plugin-abil – genereaza site cu roapoarte pentru proiect
  • conventii in defavoarea configurarii
  • adoptat de curand de foarte multe proiecte – cateva in care l-am observat eu: jasper intelligence, magnolia, jackrabbit, andromda
  • folosit cu success in 2 proiecte pana acum

IDE-uri

Am lucrat si cu JBuilder in tineretile mele – mai ales pentru SWING - dar cu siguranta supravietuitoarele dintre IDE-urile de Java sunt urmatoarele:

Elipse

  • open source, extrem de plugin-abil (suite de plugin-uri gen MyEclipse, Exadel)
  • multe alte IDE-uri s-au orientat spre el adoptand-ul (Weblogic Studio, JBuilder, WS)
  • plugin-uri aporape pentru orice
  • folosit alternativ cu Intelij Idea

Intelij Idea

  • commercial
  • orientat 100% spre Java
  • l-am folosit alternativ cu Eclipse

Net Beans

  • doar l-am incercat pntru profilerul incorporat si am inteles ca are support bun pentru JDK 1.5
Viki Pages


Confluence (commercial Atlassian)

  • usor de instalat si folosit
  • produs de Atlassian


Profilers


JProfiler (comercial - ej-technologies)

  • o unelta superba
  • optimizari reale si cu success realizate cu el
  • vizualizare timpi de executie si memorie in timp real (nu cu dump-uri asa cum e in YourKit)

Perforamanta

JMeter

  • unealta open source de la Apache (o unealta utila)
  • foarte configurabil si usor de utilizat
  • interfata Swing destul de saracacioasa

Load Runner (comercial)

  • usor de instalat si folosit
  • genereaza automat rapoarte

Instalere

Install Anywhere

  • la vremea lui installer profesionist pentru Java
  • unele din unelte mari Java sunt impachetate cu el
  • a intrat intr-un con de umbra in ultimul timt (Install4j al celor de la ej-technologies pare a fi inlocuitorul)

IzPack

  • l- am folosit pentru a impacheta aplicatiile mele Swing
  • relativ simplu dar isi face treaba
  • am vazut istalere pentru aplicatii Web create cu el - Luntbuild

Revenire

In cele din urma am decis sa revin pe scena. A trecut foarte mult timp de la ultimul post. Motivul absentei: am fost absorbit de munca.

In ultimile zile am incercat sa-mi clarific procesul de building pentru aplicatiile enterprise.

In fapt calculatorul este prin definitie o bicicleta a mintii. Deci procesul de build poate si trebuie automatizat. Dar cum se face acest lucru? Cum putem inbina toate uneltele pe care le avem pentru a automatiza procesul de build astfel incat noi sa ne ocupam doar de dezvoltare?

Am incercat pentru asta sa-mi recapitulez uneltele pe care le-am folosit in cei 5 ani de dezvolare in Java, cu impresiile corespunzatoare. Pe unele le-am folosit doar in cadrul firmelor. Pe altele le-am instalat si le-am folosit. Unele le folosesc in mod curent cu succes. Altele au ramas la stadiul de test. Lista lor in urmatorul post.