Maven Versioning Strategy (VR)

VERSIONING STRATEGY

MAVEN VERSIONING STRATEGY

SUBVERSION

O Subversion ou simplesmente SVN, é um sistema de controle de versão desenvolvido para ser o substituto do CVS.

Fundado em 2000 pela CollabNet, Inc., e desenvolvido como um projeto da Apache Software Foundation.

A versão 1.0 do Subversion (lançada em 23 de Fevereiro de 2004) possui vantagens em relação ao seu concorrente mais antigo CVS, como por exemplo ”commits" mais atômicos e releases mais consistentes.

Atualmente na versão 1.8 (Junho de 2013)

http://subversion.apache.org/docs/release-notes/

GIT VERSUS SUBVERSION

SUBVERSION

Arquitetura centralizada (Cliente-Servidor)

Depende de uma conexão de rede estabelecida com o repositório central

Funciona muito bem quando o repositório central está na mesma rede local.

SUBVERSION

Arquitetura distribuída (peer-to-peer)

Não depende de conexão para realizar o “commit" do código

Atende equipes com centenas de desenvolvedores

Funciona bem quando a equipe está espalhada em diversas filiais da empresa

O repositório “central”, quando existe, tem o papel do repositório “oficial” e não como processador central das requisições.

Maior complexidade

(peer-to-peer)

commit/update local

Pull: Atualiza o repositório local com todas as alterações feitas em outro repositório.

Push: Envia as alterações do repositório local para um outro repositório.

A sincronização entre os desenvolvedores acontece de repositório a repositório e não existe, um repositório mais importante que o outro, embora o papel de um repositório central possa ser usado para convencionar o fluxo de trabalho.

No centralizado, os desenvolvedores trabalham no mesmo branch, seja esse a Trunk ou um branch.

O modelo distribuído é mais complicado. Na arquitetura peer-to-peer, os branches e os merges aparentemente desordenados podem tornar o grafo da evolução do projeto confuso à primeira vista.

Comparativo de operações no modelo centralizado e distribuído

Qual é o melhor?

Depende do seu cenário de trabalho!

MAVEN VERSIONING STRATEGY

FOCA no objetivo!

O que é o Maven?

Ferramenta para gerenciamento de dependências e construção de artefatos (projetos).

Como é o processo hoje para construir, versionar, publicar no repositório (Nexus) e realizar o deploy da aplicação no servidor de aplicações (WebSphere)?

1. Cria-se o projeto com maven e define a versão inicial 1.0.0

2. Adiciona funcionalidades ao projeto durante o sprint (Scrum)

3. Antes do pacote de change, altera-se a versão do pom.xml manualmente.

3. Antes do pacote de change, altera-se a versão do pom.xml manualmente. altera a versão…

release + 1

COMO ASSIM???

MAVEN4. Envia (commit) o código para o servidor de controle de versão

5. Realiza a construção do artefato (build do projeto)

5. Realiza a construção do artefato (build do projeto)profile websphere, lembrou?

6. Publica o artefato no maven proxy (em breve Nexus)

profile websphere, lembrou?

7. Quando dá vontade, faz a branch da TAG da versão

8. Antes de colocar em produção, publica-se no ambiente de testes e posteriormente homologação.

release + 1 ?

release + 1 ? Quando?

1 . ? . ?

1 . ? . ? - ?

Qual estratégia utilizar para incrementar a versão do projeto?

1 . ? . ? - ?

SNAPSHOTS

Primeiro de tudo, SNAPSHOT não é a mesma coisa que alpha/beta ou milestone. É uma palavra-chave que significa a última versão do seu código. Aquela em desenvolvimento! Ou seja, ela muda!

Se você fizer o checkout do código ‘plataforma-1.5.0-SNAPSHOT' hoje e baixar a mesma versão mais tarde, muito provavelmente ele NÃO será o mesmo.

Isto também significa que se o seu projeto depende de uma versão SNAPSHOT, o maven precisará checar o repositório remoto por mudanças toda hora que você compilar o projeto.

RELEASES

Então o que é uma release?

Release não significa que a sua versão está pronta para ir à produção.

Significa que o desenvolvedor decidiu que a este ponto do desenvolvimento o código deve ser “lockado”, ou seja, não irá se perder ou ser alterado.

Talvez o time de desenvolvimento quer apenas distribuir este código, seja como uma biblioteca para outras áreas que precisam se adiantar em suas tarefas, ou instalá-lo em um ambiente (servidor) de testes.

Isto significa que uma release pode ser:

RELEASES

alphabeta

RELEASES

alphabetarelease candidate

RELEASES

patchproduction

VERSIONING STRATEGY

Maven strategy:

VERSIONING STRATEGY

Maven strategy:

Ex. plataforma-1.5.5-RC

VERSIONING STRATEGY

Maven strategy:

Estratégia de alguns fornecedores de mercado:

<major>.<minor>.<patch>[-<type>-<attempt>]

VERSIONING STRATEGY

Maven strategy:

Estratégia de alguns fornecedores de mercado:

Ex. plataforma-1.5.0-RC-05

VERSIONING STRATEGY

Spring framework release keywords

VERSIONING STRATEGY

JBoss Community release keywords

VERSIONING STRATEGY

major.minor.micro.Alpha[n]

major.minor.micro.Beta[n]

major.minor.micro.CR[n]

major.minor.micro.Final

General Availability

General Availabilityalmost final release

for test only

final tested release

for test only

General Availabilityalmost final releaseFor all announcements of releases of our community projects, we should not use the term GA (General Availability) or Production.

… split between community releases and long-term stable product releases (introduced in July, 2007 with EAP 4.2),

VERSIONING STRATEGY

Temos ainda,

as keywords milestone no lugar das tradicionais alpha, beta, etc.

Também utilizado em alguns projetos da RedHat.

major.minor.micro.TIMESTAMP-Mn

VERSIONING STRATEGY

<major> – é usado para indicar mudanças significativas na aplicação. Ela pode ser também uma total reescrita da versão anterior, gerando incompatibilidade de código.

VERSIONING STRATEGY

1 . 0 . 0

<major> – é usado para indicar mudanças significativas na aplicação. Ela pode ser também uma total reescrita da versão anterior, gerando incompatibilidade de código.

VERSIONING STRATEGY<minor> – Este número indica um conjunto de pequenas alterações como a inclusão de uma nova funcionalidade, representando por exemplo os Sprints de uma 'estória', baseado na metodologia Scrum.

Esta sempre será compatível com a versão anterior!

VERSIONING STRATEGY<minor> – Este número indica um conjunto de pequenas alterações como a inclusão de uma nova funcionalidade, representando por exemplo os Sprints de uma 'estória', baseado na metodologia Scrum.

Esta sempre será compatível com a versão anterior!

1 . 0 . 0

VERSIONING STRATEGY

<patch> – Indicado para representar correções de bugs que não podem esperar até que a próxima versão fique pronta. Nunca deverá incluir funcionalidades, apenas correções e deverá ser compatível com versões anteriores.

VERSIONING STRATEGY

<patch> – Indicado para representar correções de bugs que não podem esperar até que a próxima versão fique pronta. Nunca deverá incluir funcionalidades, apenas correções e deverá ser compatível com versões anteriores.

1 . 0 . 0

VERSIONING STRATEGY[<type>-<attempt>] – Esta última parte é opcional e é usada para indicar que o release não é necessariamente estável (production). Não é um número, mas um texto, como por exemplo: beta-01, RC-01, GA, etc.

Quando a versão é estável, pode-se omitir este texto ou utilizar a nomenclatura respectiva, como: FINAL, RELEASE

VERSIONING STRATEGY[<type>-<attempt>] – Esta última parte é opcional e é usada para indicar que o release não é necessariamente estável (production). Não é um número, mas um texto, como por exemplo: beta-01, RC-01, GA, etc.

Quando a versão é estável, pode-se omitir este texto ou utilizar a nomenclatura respectiva, como: FINAL, RELEASE

1 . 0 . 0 - RC -01

VERSIONING STRATEGY

Maven release plugin

VERSIONING STRATEGY

final do sprint #1

VERSIONING STRATEGY

final do sprint #1

VERSIONING STRATEGY

final do sprint #1 mvn release:prepare

VERSIONING STRATEGY

final do sprint #1 mvn release:prepare

VERSIONING STRATEGY

final do sprint #1 mvn release:prepare v.1.0.0.RC-01

VERSIONING STRATEGY

1. Verifica se não existe alteração pendente no repositório local

VERSIONING STRATEGY

2. Checa se existe dependencias por SNAPSHOTS

VERSIONING STRATEGY

3. É solicitado o nome da TAG, da release e da próxima versão de desenvolvimento (ENTER)

VERSIONING STRATEGY

3. É solicitado o nome da TAG, da release e da próxima versão de desenvolvimento (ENTER)

4. A branch da TAG da release atual é criada automaticamente no SVN

VERSIONING STRATEGY

mvn release:prepare

VERSIONING STRATEGY

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

checkout da

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

checkout da

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

checkout da

TAG build

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

checkout da

deploy

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

mvn release:prepare

checkout da

deploy

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

5. Faz o checkout do código da TAG criada anteriormente

mvn release:prepare

checkout da

deploy

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

6. Executa o ciclo de vida de build do maven (clean, build, test, install)

mvn release:prepare

checkout da

deploy

VERSIONING STRATEGY

mvn release:perform

v.1.0.0.RC-01

6. Executa o ciclo de vida de build do maven (clean, build, test, install)

7. Realiza o deploy do artefato instalado localmente no repositório remoto (Nexus)

mvn release:prepare

checkout da

deploy

VERSIONING STRATEGY

e agora?

VERSIONING STRATEGY

Jenkins (CruiseControl, Hudson, etc.)

VERSIONING STRATEGY

Jenkins, próximos passos:

VERSIONING STRATEGY

Jenkins, próximos passos:

VERSIONING STRATEGY

Jenkins, próximos passos:Configurar o Jenkins realizar o build da aplicação, executar os testes integrados, preparar a tag da versão no SVN, publicar o artefato no repositório remoto e por fim, efetuar o deploy da aplicação em ambiente de testes.

VERSIONING STRATEGY

Jenkins, próximos passos:Configurar o Jenkins realizar o build da aplicação, executar os testes integrados, preparar a tag da versão no SVN, publicar o artefato no repositório remoto e por fim, efetuar o deploy da aplicação em ambiente de testes.

VERSIONING STRATEGY

Commit

VERSIONING STRATEGY

Commit

VERSIONING STRATEGY

Commit

VERSIONING STRATEGY

Commit

VERSIONING STRATEGY

Commit

VERSIONING STRATEGY

Commit

svn polling

VERSIONING STRATEGY

Commit

svn polling

VERSIONING STRATEGY

Commit

svn polling

VERSIONING STRATEGY

Commit

svn polling

VERSIONING STRATEGY

Commit

svn polling

VERSIONING STRATEGY

Commit

svn polling

integration tests

VERSIONING STRATEGY

Commit

svn polling

integration tests

VERSIONING STRATEGY

Commit

svn polling

integration tests

VERSIONING STRATEGY

Commit

deploy

svn polling

integration tests

VERSIONING STRATEGY

Commit

deploy

svn polling

Maven release pluginintegration tests

VERSIONING STRATEGY

Commit

deploy

svn polling

VERSIONING STRATEGY

Commit

deploy

svn polling

VERSIONING STRATEGY

Commit

deploy

svn polling

deployintegration tests

VERSIONING STRATEGY

Commit

deploy

svn polling

deploy

WebSphere Application Server

integration tests

VERSIONING STRATEGY

OBRIGADO

MARCUS CARVALHO @marcus_dev

Maven Versioning Strategy (VR)

Technology

Transcript of Maven Versioning Strategy (VR)

VR 1801 assinantes

Maven - TDC FLN 2013

Jsf com hibernate, spring security e maven

Introdução ao Maven - ic.uff.brleomurta/courses/2012.2/labgc/aula5.pdf · Ant x Maven •Ant –Fortemente baseada em configuração –Procedural –Processo de construção e

SXSW VR Deck

Catalog VR

Utilizando Maven Nexus e Subversion 1

Configurando Um Projeto Java Com Spring MVC e Maven

VR LUX TÉCNICO

Apresentacao de Introdução ao Apache Maven

VR PHONE - Capitalgames

Introdução ao maven

Brand strategy

Flirting With Blue Ocean Strategy: iDate 2010 Blue Ocean Strategy Presentation

Cursinho de Maven

Case vr 2014_site

STRATEGY IKEA

Apresentação maven

Plugin Maven no Eclipse

Sistemas de Detecção e Alarmes de Incêndio ÓPTICO DE FUMAÇA - VR-F TERMOVELOCIMÉTRICO - VR-T FUMAÇA E TEMPERATURA - VR-FT VAZAMENTO DE GÁS - VR-G O O VR-FVR-TVR-FT VR-G LED