VERSIONING STRATEGY
MAVEN
MAVEN VERSIONING STRATEGY
MAVEN VERSIONING STRATEGY
SUBVERSION
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
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.
GIT VERSUS SUBVERSION
SUBVERSION
!
!
!
!
GIT VERSUS SUBVERSION
GIT
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
GIT VERSUS SUBVERSION
GIT
(peer-to-peer)
commit/update local
!
!
!
!
GIT VERSUS SUBVERSION
GIT
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.
GIT VERSUS SUBVERSION
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.
!
!
GIT VERSUS SUBVERSION
Comparativo de operações no modelo centralizado e distribuído
GIT VERSUS SUBVERSION
Qual é o melhor?
!
Depende do seu cenário de trabalho!
MAVEN VERSIONING STRATEGY
MAVEN VERSIONING STRATEGY
FOCA no objetivo!
MAVEN
O que é o Maven?
Ferramenta para gerenciamento de dependências e construção de artefatos (projetos).
MAVEN
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)?
MAVEN
MAVEN
1. Cria-se o projeto com maven e define a versão inicial 1.0.0
MAVEN
1. Cria-se o projeto com maven e define a versão inicial 1.0.0
MAVEN
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)
MAVEN
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)
MAVEN
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.
MAVEN
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.
MAVEN
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. altera a versão…
MAVEN
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. altera a versão…
release + 1
MAVEN
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. altera a versão…
release + 1
COMO ASSIM???
MAVEN
MAVEN4. Envia (commit) o código para o servidor de controle de versão
MAVEN4. Envia (commit) o código para o servidor de controle de versão
MAVEN4. Envia (commit) o código para o servidor de controle de versão
MAVEN4. Envia (commit) o código para o servidor de controle de versão
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)profile websphere, lembrou?
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)
6. Publica o artefato no maven proxy (em breve Nexus)
profile websphere, lembrou?
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)
6. Publica o artefato no maven proxy (em breve Nexus)
profile websphere, lembrou?
MAVEN4. Envia (commit) o código para o servidor de controle de versão
5. Realiza a construção do artefato (build do projeto)
6. Publica o artefato no maven proxy (em breve Nexus)
7. Quando dá vontade, faz a branch da TAG da versão
profile websphere, lembrou?
MAVEN
8. Antes de colocar em produção, publica-se no ambiente de testes e posteriormente homologação.
MAVEN
MAVEN
release + 1 ?
MAVEN
release + 1 ? Quando?
MAVEN
release + 1 ? Quando?
MAVEN
release + 1 ? Quando?
MAVEN
release + 1 ? Quando?
MAVEN
release + 1 ? Quando?
Como?
MAVEN
1 . ? . ?
release + 1 ? Quando?
Como?
MAVEN
1 . ? . ? - ?
release + 1 ? Quando?
Como?
MAVEN
Qual estratégia utilizar para incrementar a versão do projeto?
1 . ? . ? - ?
release + 1 ? Quando?
Como?
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
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:
alpha
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:
alphabeta
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:
alphabetarelease candidate
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:
alphabetarelease candidate
patch
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:
alphabetarelease candidate
patchproduction
VERSIONING STRATEGY
VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>
VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>
Ex. plataforma-1.5.5-RC
VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>
Estratégia de alguns fornecedores de mercado:
<major>.<minor>.<patch>[-<type>-<attempt>]
Ex. plataforma-1.5.5-RC
VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>
Estratégia de alguns fornecedores de mercado:
<major>.<minor>.<patch>[-<type>-<attempt>]
Ex. plataforma-1.5.5-RC
Ex. plataforma-1.5.0-RC-05
VERSIONING STRATEGY
Spring framework release keywords
VERSIONING STRATEGY
JBoss Community release keywords
VERSIONING STRATEGY
JBoss Community release keywords
VERSIONING STRATEGY
JBoss Community release keywords
!
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final
General Availability
General Availability
General Availabilityalmost final release
General Availabilityalmost final release
for test only
General Availabilityalmost final release
for test only
General Availabilityalmost final release
final tested release
for test only
General Availabilityalmost final release
final tested release
for test only
General Availabilityalmost final release
final tested release
for test only
for test only
General Availabilityalmost final release
final tested release
for test only
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
major.minor.micro.CR[n]
major.minor.micro.Final
VERSIONING STRATEGY
<major>.<minor>.<patch>[-<type>-<attempt>]
<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>.<minor>.<patch>[-<type>-<attempt>]
<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!
<major>.<minor>.<patch>[-<type>-<attempt>]
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
<major>.<minor>.<patch>[-<type>-<attempt>]
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.
<major>.<minor>.<patch>[-<type>-<attempt>]
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
<major>.<minor>.<patch>[-<type>-<attempt>]
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
<major>.<minor>.<patch>[-<type>-<attempt>]
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
<major>.<minor>.<patch>[-<type>-<attempt>]
VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final
VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final
VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final
VERSIONING STRATEGY
VERSIONING STRATEGY
Maven release plugin
VERSIONING STRATEGY
final do sprint #1
Maven release plugin
VERSIONING STRATEGY
final do sprint #1
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
1. Verifica se não existe alteração pendente no repositório local
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
1. Verifica se não existe alteração pendente no repositório local
2. Checa se existe dependencias por SNAPSHOTS
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
1. Verifica se não existe alteração pendente no repositório local
2. Checa se existe dependencias por SNAPSHOTS
3. É solicitado o nome da TAG, da release e da próxima versão de desenvolvimento (ENTER)
VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin
1. Verifica se não existe alteração pendente no repositório local
2. Checa se existe dependencias por SNAPSHOTS
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
Maven release plugin
VERSIONING STRATEGY
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout da
TAG
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout da
TAG
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout da
TAG build
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout da
TAG
deploy
build
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout da
TAG
deploy
build
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
5. Faz o checkout do código da TAG criada anteriormente
mvn release:prepare
checkout da
TAG
deploy
build
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
5. Faz o checkout do código da TAG criada anteriormente
6. Executa o ciclo de vida de build do maven (clean, build, test, install)
mvn release:prepare
checkout da
TAG
deploy
build
VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
5. Faz o checkout do código da TAG criada anteriormente
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
TAG
deploy
build
VERSIONING STRATEGY
e agora?
VERSIONING STRATEGY
Jenkins (CruiseControl, Hudson, etc.)
VERSIONING STRATEGY
Jenkins (CruiseControl, Hudson, etc.)
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
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
build
VERSIONING STRATEGY
Commit
svn polling
build
VERSIONING STRATEGY
Commit
svn polling
build
integration tests
VERSIONING STRATEGY
Commit
svn polling
build
integration tests
VERSIONING STRATEGY
Commit
svn polling
build
integration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
integration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven release pluginintegration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven release pluginintegration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven release pluginintegration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven release plugin
deployintegration tests
VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven release plugin
deploy
WebSphere Application Server
integration tests
VERSIONING STRATEGY
OBRIGADO
MARCUS CARVALHO @marcus_dev
Recommended
