1. O Subversion é um sistema de controle de versão desenvolvido para substituir o CVS. 2. Atualmente está na versão 1.8, lançada em junho de 2013. 3. O Subversion usa uma arquitetura centralizada enquanto o Git usa uma arquitetura distribuída.

1. VERSIONING STRATEGY

2. MAVEN

3. MAVENVERSIONING STRATEGY

4. MAVENVERSIONING STRATEGY

5. SUBVERSION

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/

7. GITVERSUS SUBVERSION

8. 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.

9. GITVERSUS SUBVERSION
SUBVERSION
!
!
!
!

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

11. GITVERSUS SUBVERSION
GIT
(peer-to-peer)
commit/update local
!
!
!
!

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.
!
!

14. GITVERSUS SUBVERSION
Comparativo de operações no modelo centralizado e distribuído

15. GITVERSUS SUBVERSION
Qual é o melhor?
!
Depende do seu cenário de trabalho!

16. MAVENVERSIONING STRATEGY

17. MAVENVERSIONING STRATEGY
FOCA no objetivo!

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)?

20. MAVEN

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

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

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???

30. MAVEN

31. MAVEN
4.
Envia (commit) o código para o servidor de controle de
versão

32. MAVEN
4.
Envia (commit) o código para o servidor de controle de
versão

33. MAVEN
4.
Envia (commit) o código para o servidor de controle de
versão

34. MAVEN
4.
Envia (commit) o código para o servidor de controle de
versão

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.

42. MAVEN

43. MAVEN
release + 1 ?

44. MAVEN
release + 1 ? Quando?

45. MAVEN
release + 1 ? Quando?

46. MAVEN
release + 1 ? Quando?

47. MAVEN
release + 1 ? Quando?

48. MAVEN
release + 1 ? Quando?
Como?

49. MAVEN
1 . ? . ?
release + 1 ? Quando?
Como?

50. MAVEN
1 . ? . ? - ?
release + 1 ? Quando?
Como?

51. MAVEN
Qual estratégia utilizar para incrementar a versão do projeto?
1 . ? . ? - ?
release + 1 ? Quando?
Como?

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

59. VERSIONING STRATEGY

60. VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>

61. VERSIONING STRATEGY
Maven strategy:
<major>.<minor>.<incremental>-<qualifier>
Ex. plataforma-1.5.5-RC

62. 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

63. 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

64. VERSIONING STRATEGY
Spring framework release keywords

65. VERSIONING STRATEGY
JBoss Community release keywords

66. VERSIONING STRATEGY
JBoss Community release keywords

67. 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

70. General Availability

71. General Availability

72. General Availabilityalmost final release

73. General Availabilityalmost final release

74. for test only
General Availabilityalmost final release

75. for test only
General Availabilityalmost final release

76. final tested release
for test only
General Availabilityalmost final release

77. final tested release
for test only
General Availabilityalmost final release

78. final tested release
for test only
for test only
General Availabilityalmost final release

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

81. 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.

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>]

89. VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final

90. VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final

91. VERSIONING STRATEGY
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final

92. VERSIONING STRATEGY

93. VERSIONING STRATEGY
Maven release plugin

94. VERSIONING STRATEGY
final do sprint #1
Maven release plugin

95. VERSIONING STRATEGY
final do sprint #1
Maven release plugin

96. VERSIONING STRATEGY
final do sprint #1 mvn release:prepare
Maven release plugin

97. VERSIONING STRATEGY
final do sprint #1 mvn release:prepare
Maven release plugin

98. VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin

99. VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin

100. VERSIONING STRATEGY
final do sprint #1 mvn release:prepare v.1.0.0.RC-01
Maven release plugin

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

105. VERSIONING STRATEGY
Maven release plugin

106. VERSIONING STRATEGY
Maven release plugin
mvn release:prepare

107. VERSIONING STRATEGY
Maven release plugin
mvn release:prepare

108. VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare

109. VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare

110. VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare

111. VERSIONING STRATEGY
mvn release:perform
Maven release plugin
mvn release:prepare

112. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare

113. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout
da
TAG

114. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout
da
TAG

115. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout
da
TAG build

116. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout
da
TAG
deploy
build

117. VERSIONING STRATEGY
mvn release:perform
v.1.0.0.RC-01
Maven release plugin
mvn release:prepare
checkout
da
TAG
deploy
build

118. 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

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

121. VERSIONING STRATEGY
e agora?

122. VERSIONING STRATEGY
Jenkins (CruiseControl, Hudson, etc.)

123. VERSIONING STRATEGY
Jenkins (CruiseControl, Hudson, etc.)

124. VERSIONING STRATEGY
Jenkins (CruiseControl, Hudson, etc.)

125. VERSIONING STRATEGY
Jenkins, próximos passos:

126. VERSIONING STRATEGY
Jenkins, próximos passos:

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.

129. VERSIONING STRATEGY

130. VERSIONING STRATEGY
Commit

131. VERSIONING STRATEGY
Commit

132. VERSIONING STRATEGY
Commit

133. VERSIONING STRATEGY
Commit

134. VERSIONING STRATEGY
Commit

135. VERSIONING STRATEGY
Commit
svn polling

136. VERSIONING STRATEGY
Commit
svn polling

137. VERSIONING STRATEGY
Commit
svn polling

138. VERSIONING STRATEGY
Commit
svn polling
build

139. VERSIONING STRATEGY
Commit
svn polling
build

140. VERSIONING STRATEGY
Commit
svn polling
build
integration tests

141. VERSIONING STRATEGY
Commit
svn polling
build
integration tests

142. VERSIONING STRATEGY
Commit
svn polling
build
integration tests

143. VERSIONING STRATEGY
Commit
deploy
svn polling
build
integration tests

144. VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven
release pluginintegration tests

145. VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven
release pluginintegration tests

146. VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven
release pluginintegration tests

147. VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven
release plugin
deploy
integration tests

148. VERSIONING STRATEGY
Commit
deploy
svn polling
build
Maven
release plugin
deploy
WebSphere Application Server
integration tests

149. VERSIONING STRATEGY
OBRIGADO
MARCUS CARVALHO
@marcus_dev