Maven Versioning Strategy (VR)
Upcoming SlideShare
Loading in...5
×
 

Maven Versioning Strategy (VR)

on

  • 187 views

Entendendo o versionamento de código e estratégias de integração e deploy contínuo.

Entendendo o versionamento de código e estratégias de integração e deploy contínuo.

Statistics

Views

Total Views
187
Views on SlideShare
185
Embed Views
2

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 2

http://www.slideee.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Maven Versioning Strategy (VR) Maven Versioning Strategy (VR) Presentation Transcript

  • VERSIONING STRATEGY
  • MAVEN
  • MAVENVERSIONING STRATEGY
  • MAVENVERSIONING 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/
  • GITVERSUS SUBVERSION
  • GITVERSUS 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.
  • GITVERSUS SUBVERSION SUBVERSION ! ! ! !
  • GITVERSUS 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
  • GITVERSUS SUBVERSION GIT (peer-to-peer) commit/update local ! ! ! !
  • GITVERSUS 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.
  • GITVERSUS 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. ! !
  • GITVERSUS SUBVERSION Comparativo de operações no modelo centralizado e distribuído
  • GITVERSUS SUBVERSION Qual é o melhor? ! Depende do seu cenário de trabalho!
  • MAVENVERSIONING STRATEGY
  • MAVENVERSIONING 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
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão 5. Realiza a construção do artefato (build do projeto)
  • MAVEN 4. Envia (commit) o código para o servidor de controle de versão 5. Realiza a construção do artefato (build do projeto)
  • MAVEN 4. 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?
  • MAVEN 4. 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?
  • MAVEN 4. 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?
  • MAVEN 4. 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: alpha beta
  • 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 beta release 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: alpha beta release 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: alpha beta release candidate patch production
  • 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 release For 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 deploy integration tests
  • VERSIONING STRATEGY Commit deploy svn polling build Maven release plugin deploy WebSphere Application Server integration tests
  • VERSIONING STRATEGY OBRIGADO MARCUS CARVALHO @marcus_dev