6. 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/
10. 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
12. 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.
13. 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.
!
!
18. MAVEN
O que é o Maven?
Ferramenta para gerenciamento de dependências e construção
de artefatos (projetos).
19. 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)?
23. 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)
24. 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)
25. 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.
26. 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.
27. 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…
28. 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
29. 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???
35. 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)
36. 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)
37. 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?
38. 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?
39. 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?
40. 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?
41. MAVEN
8.
Antes de colocar em produção, publica-se no ambiente de
testes e posteriormente homologação.
52. 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.
53. 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:
54. 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
55. 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
56. 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
57. 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
58. 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
79. 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),
80. 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
82. 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.
83. 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>]
84. 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>]
85. 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>]
86. 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>]
87. 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>]
88. 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>]
101. 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
102. 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
103. 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)
104. 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
119. 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
120. 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
127. 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.
128. 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.