UNIVERSIDADE DO SUL DE SANTA CATARINA FRANCISCO ALMEIDA FRANÇA
GUILHERME CÉSAR MEDEIROS
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE:
ANÁLISE PRÁTICA DE SISTEMAS DE CONTROLE DE VERSÃO
Palhoça 2016
1 FRANCISCO ALMEIDA FRANÇA
GUILHERME CÉSAR MEDEIROS
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE:
ANÁLISE PRÁTICA DE SISTEMAS DE CONTROLE DE VERSÃO
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Ciência da Computação.
Orientador: Prof. Saulo Popov Zambiasi , Dr.
Palhoça 2016
3
Dedicamos nosso TCC a toda nossa família, pelo apoio e esforço investido sobre nós durante todos esses anos.
4
Resumo
No processo de desenvolvimento de software pode-se haver o gerenciamento inadequado de código quando o desenvolvimento se dá de forma paralela em equipe. Neste sentido, este projeto objetiva mostrar as características do sistema de controle de versão para o desenvolvimento de software através de pesquisa teórica e aplicação prática. A pesquisa teórica realizada neste trabalho aborda os conceitos gerais da gerência de configuração de software e seus principais componentes, assim como os principais conceitos dos sistemas de controle de versão. Na sequência do trabalho foi realizada a aplicação prática das principais operações com os sistemas de controle de versão Subversion, Git e Mercurial em forma de um tutorial explicativo. Com base na abordagem teórica e prática desenvolvida foi realizada uma análise comparativa com alguns requisitos considerados interessantes, a partir da análise realizada foi possível recomendar a escolha de um sistema de controle de versão para o uso.
5
Abstract
In the software development process can be has inadequate management of code when the development occurs at the same time in team. Thus, this project aims to show the features of version control system for software development through theoretical and practical application research. The theoretical research carried out in this paper discusses the general concepts of software configuration management and its key components, as well as the main concepts of the version control systems. Following the work the practical application was carried with the main operations of the version control system Subversion, Git and Mercurial in the form of an explanatory tutorial. Based on the theoretical and practical approach developed was carried out a comparative analysis with some interesting points, from the analysis it was possible to recommend the choice of a version control system for use.
6
Lista de Ilustrações
Figura 1 - Comando de Instalação do Subversion 57
Figura 2 - Comando para Verificar Versão do Subversion 58
Figura 3 - Comando help do Subversion 59
Figura 4 - Criar um Repositório Subversion 60
Figura 5 - Criação de diretório no Repositório Subversion 60
Figura 6 - Mensagem de Criação de Diretório no Subversion 61
Figura 7 - Criação de Cópia de Trabalho no Subversion 1 62
Figura 8 - Listagem da Criação da Cópia de Trabalho no Subversion 62
Figura 9 - Listagem do conteúdo da Cópia de Trabalho no Subversion 62
Figura 10 - Adição de Arquivos no Subversion 1 62
Figura 11 - Adição de Arquivos no Subversion 2 63
Figura 12 - Adição de Arquivos no Subversion 3 63
Figura 13 - Commit no Subversion 1 64
Figura 14 - Alteração de Arquivo no Subversion 1 64
Figura 15 - Comando Status no Subversion 64
Figura 16 - Commit no Subversion 2 65
Figura 17 - Importação de Arquivos no Subversion 65
Figura 18 - Update da Cópia de Trabalho no Subversion 1 66
Figura 19 - Remoção de Arquivo no Subversion 66
Figura 20 - Commit no Subversion 3 66
Figura 21 - Cópia de Arquivos no Subversion 67
Figura 22 - Exclusão direta de arquivo no Subversion 67
Figura 23 - Restauração de arquivo através de update no Subversion 68
Figura 24 - Mover Arquivos no Subversion 1 68
Figura 25 - Mover Arquivos no Subversion 2 69
Figura 26 - Comando Diff no Subversion 1 69
Figura 27 - Comando Diff no Subversion 2 70
Figura 28 - Alteração de Arquivo no Subversion 2 71
Figura 29 - Comando Revert no Subversion 71
Figura 30 - Arquivo restaurado no Subversion 71
Figura 31 - Merge entre Revisões no Subversion 72
Figura 32 - Arquivo restaurado com Merge no Subversion 72
Figura 33 - Criação de cópia de trabalho no Subversion 2 73
Figura 34 - Conteúdo da cópia do Branch no Subversion 1 73
Figura 35 - Criação de Branche no Subversion 1 73
Figura 36 - Criação de cópia de trabalho no Subversion 3 74
Figura 37 - Conteúdo da cópia do Branch no Subversion 2 74
Figura 38 - Adição de Arquivos no Subversion 4 74
Figura 39 - Criação de cópia de trabalho no Subversion 4 75
Figura 40 - Criação de Tag no Subversion 75
Figura 41 - Alteração de Arquivo no Subversion 3 76
Figura 42 - Alteração de Arquivo no Subversion 4 76
Figura 43 - Commit no Subversion 4 76
Figura 44 - Update da Cópia de Trabalho no Subversion 2 77
Figura 45 - Lista de Opções no Subversion 77
Figura 46 - Comparação de arquivo no Subversion 78
Figura 47 - Atualização de Pacotes no Linux 79
7
Figura 49 - Comando para Verificar Versão do Git 79
Figura 50 - Configuração de Usuário no Git 80
Figura 51 - Configuração de e-mail no Git 80
Figura 52 - Conteúdo do arquivo “.gitconfig” no Git 80
Figura 53 - Criar um Repositório Git 81
Figura 54 - Conteúdo no Repositório no Git 1 81
Figura 55 - Criação de Clone de Repositório Git 1 82
Figura 56 - Comando Help no Git 82
Figura 57 - Ciclo de Vida de Arquivo no Git 83
Figura 58 - Listagem de Projeto Clonado no Git 1 83
Figura 59 - Comando Status no Git 1 84
Figura 60 - Adição do arquivo “Principal.java” no Git 84
Figura 61 - Comando Status no Git 2 85
Figura 62 - Adição de Arquivos no Git 1 85
Figura 63 - Comando Status no Git 3 85
Figura 64 - Conteúdo do arquivo “Principal.java” no Git 2 86
Figura 65 - Comando Status no Git 4 86
Figura 66 - Adição de Arquivos no Git 2 86
Figura 67 - Comando Status no Git 5 87
Figura 68 - Commit no Git 1 87
Figura 69 - Comando Log no Git 1 87
Figura 70 - Árvore de Log no Git 1 88
Figura 71 - Comando Gitk no Git 1 89
Figura 72 - Janela do Gitk no Git 89
Figura 73 - Listagem de Projeto Clonado no Git 2 90
Figura 74 - Conteúdo do arquivo “.gitignore” no Git 1 90
Figura 75 - Conteúdo do arquivo “.gitignore” no Git 2 91
Figura 76 - Comando Status no Git 6 91
Figura 77 - Adição de Arquivos no Git 3 91
Figura 78 - Listagem de Projeto Clonado no Git 3 92
Figura 79 - Comando Status no Git 7 92
Figura 80 - Árvore de commit no Git 1 93
Figura 81 - Exclusão de commit 93
Figura 82 - Árvore de commit no Git 2 94
Figura 83 - Comando Git reflog 1 94
Figura 84 - Retorno do comando reflog 95
Figura 85 - Comando merge no Git 1 95
Figura 86 - Árvore de commit no Git 3 95
Figura 87 - Conteúdo do Arquivo Pessoa 97
Figura 88 - Comando Status no Git 8 97
Figura 89 - Comando Status no Git 9 97
Figura 90 - Comando para enviar alterações para stash 97
Figura 91 - Comando Status no Git 10 97
Figura 92 - Comando de listagem do stash 98
Figura 93 - Retorno de listagem do stash 98
Figura 94 - Comando stash apply 1 98
Figura 95 - Comando stash apply 2 98
Figura 96 - Listagem de branchs 1 99
Figura 97 - Criação de branch no git 1 99
8
Figura 99 - Checkout branch master no git 1 100
Figura 100 - Log de commit no git 1 100
Figura 101 - Exclusão do último commit 101
Figura 102 - Log de commit no git 2 101
Figura 103 - Checkout branch desenvolvimento 101
Figura 104 - log do branch desenvolvimento 102
Figura 105 - árvore de commits sem rebase 102
Figura 106 - árvore de commits depois do rebase 103
Figura 107 - comando gitk no git 103
Figura 108 - Janela do Gitk 1 103
Figura 109 - branch atual no git 104
Figura 110 - Nova linha em “Pessoa.java” 104
Figura 111 - Status do arquivo”Pessoa.java” 104
Figura 112 - Adicionar alteração ao índice 105
Figura 113 - Commit da alteração realizada 105
Figura 114 - Árvore atualizada no gitk 105
Figura 115 - Alternar para branch desenvolvimento 105
Figura 116 - Alteração do “Pessoa.java em desenvolvimento 106
Figura 117 - Merge entre desenvolvimento e master 106
Figura 118 - Status de conflito no git 107
Figura 119 - Conteúdo o arquivo em conflito 107
Figura 120 - Arquivo resolvido 107
Figura 121 - Commit após resolução 108
Figura 122 - Grafo após o merge realizado 108
Figura 123 - árvore atualizada no gitk 108
Figura 124 - Nova linha arquivo “Pessoa.java” 109
Figura 125 - árvore atualizada no gitk 2 109
Figura 126 - árvore de commits grande 109
Figura 127 - execução do rebase 110
Figura 128 - árvore após rebase 110
Figura 129 - Clonagem do repositório remoto 108
Figura 130 - Origem do repositório remoto 108
Figura 131 - Adição de repositório remoto 109
Figura 132 - Listagem dos repositório remotos 109
Figura 133 - Utilização de nome curto 109
Figura 134 - Comando remote show no Git 110
Figura 135 - Listagem de todos branches 110
Figura 136 - Checkout de branch remoto 111
Figura 137 - Pull do branch teste 111
Figura 138 - Commit no branch local 112
Figura 139 - Status do branch local 112
Figura 140 - Push para o repositório remoto 113
Figura 141 - Status do repositório no Github 114
Figura 142 - Comando de Instalação do Mercurial 116
Figura 143 - Comando para Verificar versão do Mercurial 116
Figura 144 - Comando Help do Mercurial 116
Figura 145 - Comando Help do Mercurial 2 117
Figura 146 - Criação de Repositório no Mercurial 1 118
Figura 147 - Criação de Repositório no Mercurial 2 118
9
Figura 149 - Localização do arquivo “hgrc” 119
Figura 150 - Conteúdo do arquivo “hgrc” 119
Figura 151 - Adição de Arquivos no Mercurial 1 120
Figura 152 - Comando Status no Mercurial 1 120
Figura 153 - Commit no Mercurial 1 120
Figura 154 - Comando log no Mercurial 1 121
Figura 155 - Alteração de arquivo no Mercurial 1 121
Figura 156 - Comando Status no Mercurial 2 121
Figura 157 - Commit no Mercurial 2 122
Figura 158 - Comando log no Mercurial 2 122
Figura 159 - Exclusão do Arquivo “arquivo1” no Mercurial 122
Figura 160 - Comando Revert no Mercurial 122
Figura 161 - Comando Status no Mercurial 3 123
Figura 162 - Comando diff no Mercurial 1 123
Figura 163 - Comando remove no Mercurial 124
Figura 164 - Criação de clone no Mercurial 1 124
Figura 165 - Conteúdo do arquivo “hgrc” 2 125
Figura 166 - Commit no Mercurial 3 125
Figura 167 - Comando Push no Mercurial 1 126
Figura 168 - Comando pull no Mercurial 1 126
Figura 169 - Criação do branch “testeBranch” no Mercurial 127
Figura 170 - Adição de arquivo no branch “testeBranch” no Mercurial 127
Figura 171 - Comando update para alternar entre branches no Mercurial 127
Figura 172 - Atualização do clone no Mercurial 1 128
Figura 173 - Alternando branch no Mercurial 1 128
Figura 174 - Alternando branch no Mercurial 2 128
Figura 175 - Comando Merge no Mercurial 129
Figura 176 - Novos clones criados no Mercurial 129
Figura 177 - Conteúdo do arquivo “arquivo4” no Mercurial 1 130
Figura 178 - Conteúdo do arquivo “arquivo4” no Mercurial 2 130
Figura 179 - Commit no Mercurial 4 130
Figura 180 - Atualização do clone no Mercurial 2 131
Figura 181 - Janela da ferramenta Meld mostrando as diferenças 131
Figura 182 - Comando resolve do Mercurial 132
Figura 183 - Botão adicionar Repositório 150
Figura 184 - Opção Novo Repositório 150
Figura 185 - Campos do cadastro de novo repositório 151
Figura 186 - Comando de Instalação do Git 152
Figura 187 - Verificar versão do Git instalado 152
Figura 188 - Comando de instalação do pacote versão 8 do Java 153
Figura 189 - Comando para verificar versão do Java 153
Figura 190 - Caminho de instalação do JDK 153
Figura 191 - Comando para editar o arquivo “bash.bashrc” 154
Figura 192 - Edição do arquivo “bash.bashrc” 154
Figura 193 - Comando para verificar versão do compilador Java 154
Figura 194 - Opções de download do Maven 155
Figura 195 - Copiar endereço do link 155
Figura 196 - Comando para baixar o pacote do Maven 155
Figura 197 - Comando para descompactar o pacote do Maven 156
10
Figura 199 - Comando para verificar a versão do Maven 156
Figura 200 - Opção em destaque para baixar o Tomcat 157
Figura 201 - Comando para baixar o Tomcat 157
Figura 202 - Conteúdo do arquivo “tomcat” 158
Figura 203 - Comando para alterar permissões do arquivo “tomcat” 159
Figura 204 - Comando para habilitar script tomcat 159
Figura 205 - Comando para alterar nível do processo tomcat 159
Figura 206 - Comando para verificar configuração do processo Tomcat 159
Figura 207 - Comando para reiniciar o serviço tomcat 160
Figura 208 - Caminho da pasta “conf” do tomcat 160
Figura 209 - Conteúdo do arquivo “tomcat-users.xml” 161
Figura 210 - Botão “Manager App” 161
Figura 211 - Caminho do diretório “webapps” 162
Figura 212 - Opções de download do pacote Jenkins 162
Figura 213 - Download do pacote Jenkins na pasta “webapps” 162
Figura 214 - Reiniciar serviço do tomcat 162
Figura 215 - Opção gerenciar Jenkins 163
Figura 216 - Opção Gerenciar plugins 163
Figura 217 - Pesquisar plugins já instalados no Jenkins 164
Figura 218 - Instalação de plugins no Jenkins 164
Figura 219 - Opção configurar o sistema 165
Figura 220 - Configuração do Git no Jenkins 165
Figura 221 - Botão maven instalações 165
Figura 222 - Configuração do Maven no Jenkins 166
Figura 223 - Acessar o root no Jenkins 166
Figura 224 - Comando para criação de chaves no Jenkins 167
Figura 225 - Conteúdo da pasta “.ssh” 167
Figura 226 - Conteúdo da chave pública 168
Figura 227 - Opção settings no Github 168
Figura 228 - Opção SSH Keys no Github 168
Figura 229 - Opção New SSH Key 169
Figura 230 - Configuração de chave SSH no Github 169
Figura 231 - Botão Add SSH key 169
Figura 232 - Comando clone do repositório 169
Figura 233 - Retorno do comando clone do repositório 170
Figura 234 - Botão Credentials do Jenkins 170
Figura 235 - Opção Global credentials no Jenkins 170
Figura 236 - Opção Add Credentials no Jenkins 170
Figura 237 - Conteúdo do campo Kind 171
Figura 238 - Campos Scope, Username, Private Key e Passphrase 171
Figura 239 - Botão Ok para criar credencial no Jenkins 171
Figura 240 - Opção Novo Job no Jenkins 172
Figura 241 - Tela de Cadastro de Job no Jenkins 172
Figura 242 - Opção de link para acesso SSH no Github 173
Figura 243 - Formulário de cadastro do repositório no Jenkins 173
Figura 244 - Opção Consultar periodicamente o SCM no Jenkins 173
Figura 245 - Opção de ação Deploy war/ear to container 174
Figura 246 - Configuração de ação no Jenkins 174
Figura 247 - Configuração de usuário e senha Tomcat no Jenkins 174
11
Figura 249 - Log de Construção do Jenkins 175
Figura 250 - Opções de download do Java 8 176
Figura 251 - Tela do Windows Explorer 177
Figura 252 - Opções de Gerenciamento e Configuração 177
Figura 253 - Tela de configurações avançadas do Sistema 178
Figura 254 - Tela de configuração de variáveis de ambiente 178
Figura 255 - Declaração de variável de ambiente no Windows 179
Figura 256 - Visualização de variáveis de ambiente no terminal 179
Figura 257 - Declaração da variável classpath 180
Figura 258 - Alteração da variável de ambiente Path 180
Figura 259 - Verificação de versão do Java no Windows 181
Figura 260 - Opções de download do Maven 181
Figura 261 - Variável de ambiente do Maven 182
Figura 262 - Edição da variável de ambiente path 182
Figura 263 - Verificação da versão do Maven no Windows 183
Figura 264 - Visualizar informações sobre o Eclipse 183
Figura 265 - Representação do Maven no Eclipse 184
Figura 266 - Janela de informações gerais sobre o Eclipse 184
Figura 267 - Verificar configuração do JDK no Eclipse 184
Figura 268 - Janela de configuração das JREs no Eclipse 185
Figura 269 - Preenchimento de nova JRE no Eclipse 186
Figura 270 - Criação de projeto Maven no eclipse 187
Figura 271 - Preenchimento de cadastro do novo projeto Maven 187
Figura 272 - Janela de seleção de arquétipo 188
Figura 273 - Preenchimento do arquétipo do novo projeto maven 189
Figura 274 - Execução de Maven build no Eclipse 190
Figura 275 - Janela de execução do Maven Build 191
Figura 276 - Retorno da execução do Maven build no eclipse 191
Figura 277 - Configuração da tecnologia JSP no Maven 192
Figura 278 - Configuração de plugin War no Maven 192
Figura 279 - Janela de seleção dos componentes Git 193
Figura 280 - Ajustes de instalação do Git 1 194
Figura 281 - Ajustes de instalação do Git 2 195
Figura 282 - Ajustes de instalação do Git 3 196
Figura 283 - Atalho do terminal Git 197
Figura 284 - Comando para gerar chaves 197
Figura 285 - Opção Clonar/Novo no SourceTree 198
Figura 286 - Opções de repositório no SourceTree 198
Figura 287 - Tela de configuração de repositório no SourceTree 198
Figura 288 - Adicionar repositório remoto no SourceTree 199
Figura 289 - Cadastro de repositório remoto 199
12
Lista de Quadros
Quadro 1 - Quadro comparativo de sistemas de controle de versão 49 Quadro 2 - Características da pesquisa quantitativa e qualitativa 53 Quadro 3 - Quadro analítico dos sistemas aplicados 138
Lista de Tabelas
13 SUMÁRIO 1 INTRODUÇÃO 18 1.1 PROBLEMÁTICA 19 1.2 OBJETIVOS 20 1.2.1 Objetivo Geral 21 1.2.2 Objetivos Específicos 21 1.3 JUSTIFICATIVA 21 1.4 ESTRUTURA DO TRABALHO 22 2 REVISÃO BIBLIOGRÁFICA 23
2.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE E QUALIDADE 23
2.2 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE 24
2.2.1 Itens de Configuração de Software (SCI - Software Configuration Items) 26
2.2.2 Gestão de Mudanças 26
2.2.3 baseline e codeline 26
2.3 DEVOPS 27
2.4 CONTROLE DE VERSÃO 28
2.4.1 Sistema Centralizado e Sistema Distribuído 30
2.4.1.2 Repositório Remoto e Desenvolvimento Colaborativo 31
2.4.2 TRUNK, BRANCHING E MERGING 32
2.4.3 Operações e Conceitos comuns dos sistemas de controle de versão 33
2.4.3.1 commit 33
2.4.3.2 pull or update 34
2.4.3.3 push 34
2.4.3.4 checkout e cópia de trabalho 34
2.4.3.5 merge 34 2.4.3.6 resolve 35 2.4.3.7 lock 35 2.4.3.8 tag 35 2.4.3.9 log 35 2.4.3.10 create 36
14 2.4.3.11 add 36 2.4.3.12 edit 36 2.4.3.13 delete 36 2.4.3.14 diff 36 2.4.3.15 revert 37 2.4.3.16 move 37 2.4.3.17 rename 37 2.4.3.18 head 37 2.5 SUBVERSION 38 2.5.1 Funcionamento Básico 38
2.5.2 Estrutura Básica do Repositório e Acesso 39
2.5.3 Trunk, Branches e Tags 40
2.5.4 Cópia de Trabalho 41
2.6 GIT 42
2.6.1 Funcionamento Básico 42
2.6.2 Repositório e Cópia de Trabalho 43
2.6.3 Branch e Merge com Git 44
2.7 MERCURIAL 45
2.7.1 Funcionamento Básico e Compatibilidade 45
2.7.2 Repositório 46
2.7.3 Cópia de Trabalho 46
2.7.4 Branch e Merge no Mercurial 47
2.8 COMPARAÇÃO RESUMIDA DE RECURSOS 47
2.9 GERENCIAMENTO DE CONTROLE DE VERSÃO 49
3 METODOLOGIA DE PESQUISA 49
3.1 CARACTERÍSTICA DO TIPO DE PESQUISA 49
3.1.1 Natureza de Pesquisa 50 3.1.2 Abordagem 50 3.1.2.1 Qualitativa 50 3.1.2.2 Quantitativa 51 3.1.3 Objetivo 52 3.2 PROCEDIMENTOS 53
15
3.3 DELIMITAÇÕES 55
3.4 ETAPAS METODOLÓGICAS 55
4 FERRAMENTAS (MATERIAIS E MÉTODOS) 56
4.1 APLICAÇÃO DO SUBVERSION 56 4.1.1 Instalação e Ajuda 56 4.1.2 Repositório 59 4.1.3 Cópia de Trabalho 60 4.1.4 Adição de Arquivos 61 4.1.5 Status e Commit 63 4.1.6 Importação de Arquivos 64 4.1.7 Remoção de Arquivo 65 4.1.8 Cópia 66
4.1.9 Restauração Através de Update 66
4.1.10 Mover 67
4.1.11 Diff 68
4.1.12 Reversão com Revert e Merge 70
4.1.13 Branch e Tags 71
4.1.14 Conflito 74
4.2 APLICAÇÃO DO GIT 78
4.2.1 Instalação e Configuração de Usuário 78
4.2.2 Operações com o Git 79
4.2.2.1 - Inicialização de Repositório 79
4.2.2.2 - Commit, Stage, working directory e status 81
4.2.2.3 Ignorar arquivos 89
4.2.2.4 - Git Reflog 91
4.2.2.5 Stash 95
4.2.2.6 - Branch 98
4.2.2.7 - Merge e Rebase 101
4.2.2.8 Repositório e Branch Remoto no Git 110
4.3 APLICAÇÃO DO MERCURIAL 116
4.3.1 Instalação e Ajuda 116
16
4.3.3 Usuário 120
4.3.4 Adição de Arquivos e Status 120
4.3.5 Log 121 4.3.6 Revert 123 4.3.7 Diff 124 4.3.8 Remove 124 4.3.9 Cópia de Trabalho(Clone) 125 4.3.10 Push 126 4.3.11 Pull 127 4.3.12 Branch e Merge 128 4.3.13 Conflito 130
5 ANÁLISE DOS SISTEMAS APLICADOS 134
5.1 INSTALAÇÃO, CONFIGURAÇÃO E COMPATIBILIDADE 134
5.2 DOCUMENTAÇÃO 135
5.3 CURVA DE APRENDIZAGEM E USABILIDADE 135
5.4 GERENCIAMENTO E ESTRUTURA DE REPOSITÓRIO 136
5.5 GERENCIAMENTO E ESTRUTURA DE CÓPIA DE TRABALHO 136
5.6 GERENCIAMENTO DE BRANCHES 137
5.7 DESEMPENHO EM COMANDOS 137
5.8 RESUMO COMPARATIVO 138
5.9 CONSIDERAÇÕES 140
6 - CONCLUSÃO 141
6.2 - Sugestão para trabalhos futuros 142
REFERÊNCIAS 143
APÊNDICE A - INSTALAÇÃO E CONFIGURAÇÃO DE AMBIENTE PARA
INTEGRAÇÃO CONTÍNUA 147
17
1 INTRODUÇÃO
A tecnologia está fortemente presente no cotidiano e parte dela é baseada em software. Para Pressman(2011) um software consiste em:
(1) instruções (programas de computador) que, quando executadas, fornecem características, funções e desempenho desejados;(2)estruturas de dados que possibilitam aos programas manipular informações adequadamente; e (3) informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso dos programas. (PRESSMAN, 2011, p.32).
Sob uma visão estatística, a ABES (Associação Brasileira de Empresas de Software) cita que o Brasil cresceu 15,4% em investimentos no mercado de TI, incluindo o desenvolvimento de software, de 2012 para o final de 2013, chegando a um total de 61,6 bilhões de dólares. Esses dados demonstram a crescente dependência das pessoas em relação aos produtos de software, tais como redes sociais, home bankings1, sistema de gestão empresarial, sistemas da área da saúde.
Nesse sentido, para atender a demanda em tal proporção, Ventorin (2013) relata que os softwares estão cada vez mais complexos, assim como os sistemas que os agrupam. O mercado mostra uma alta na busca de automação. Como consequência disso, percebe-se também o aumento na demanda de sistemas. Sendo assim é necessário um conjunto de processos e boas práticas para analisar, organizar e melhorar o desenvolvimento de sistemas computacionais, com foco em atender aos requisitos do negócio do cliente ou qualquer que seja a função do sistema.
Frente aos grandes problemas e prejuízos, decorrentes de falta de qualidade, que circundam até o final da década de 60, surgiram as primeiras preocupações de existir formas mais organizáveis de se fazer as coisas, com objetivo claro de trazer um desenvolvimento e manutenção com mais qualidade. Conforme Gibbs:
A arte da programação levou 50 anos de contínuo aperfeiçoamento para alcançar um estágio aceitável. No momento em que chegava aos 25 anos, as dificuldades na construção de grandes softwares eram tão grandes que, no Outono de 1968 o Comité Científico da OTAN reuniu cerca de 50 programadores de nível mundial, cientistas da computação e chefes da indústria para traçar um curso para fora do que veio a ser conhecido como a crise do software. Embora peritos técnicos não pudessem inventar
1 Home bankng é um serviço oferecido por alguns bancos a seus clientes, que permite a operação de suas contas através da internet.
18 um roteiro para orientar a indústria em direção à terra firme, eles deram um nome para esse objetivo distante: engenharia de software, agora definida formalmente como "a aplicação de uma disciplina, uma abordagem sistemática e quantificável para o desenvolvimento, operação e manutenção de software. (GIBBS, 1994, p. 86)
A partir desse início da área de engenharia de software, através de um prisma mais formalizado e com importância dada, o mercado começou a busca por soluções. Foram criadas, a partir de então, diversas subáreas para estes problemas específicos, entre elas a gerência de configuração de software.
1.1 PROBLEMÁTICA
No desenvolvimento de software a falta de organização e planejamento na execução de mudanças pode acarretar problemas. Um controle ineficaz durante o desenvolvimento de um produto de software torna o seu projeto muito confuso. Segundo Pressman:
[...]mudanças são inevitáveis quando o software é construído. E as mudanças aumentam o nível de confusão entre os membros de uma equipe de software que estão trabalhando em um projeto. A confusão surge quando as mudanças não são analisadas antes de ser feitas, não são registradas antes de ser implementadas, não são relatadas àqueles que precisam saber, ou não são controladas de uma maneira que melhore a qualidade e reduza os erros (PRESSMANN, 2011, p. 537).
Seguindo o raciocínio de Pressman, ainda outro fator que a ser considerado, é que em todos os softwares, durante o andamento dos seus ciclos de desenvolvimento, passam por modificações. Ainda seguindo nesse raciocínio, Pressman (2011, p.517) afirma que
a alteração é um fato normal no desenvolvimento de software. Clientes querem modificar requisitos. Desenvolvedores querem modificar a abordagem técnica. Gerentes querem modificar a estratégia do projeto.” (PRESMAN, 2011, p.517).
Quase toda evolução de um sistema ou uma tecnologia qualquer e mais especificamente computacional, requer recursos e esses por sua vez, são custosos, sendo assim, boas práticas voltadas para integrar mudanças e alterações se tornam uma constante necessidade.
A arte de coordenar desenvolvimento de software para minimizar a… Confusão é chamada de gestão de configuração. A gestão de configuração é a arte de identificar, organizar e controlar modificações no software que esta sendo criado por uma equipe de programação. O objetivo é maximizar a produtividade minimizando erros (BABICH APUD PRESMANN, 2011, p. 537).
19
Para Dantas (2013,p.01), "a ausência da gerência de configuração nos moldes de desenvolvimento de softwares atuais fica impossível para qualquer equipe de desenvolvimento".
Como já apontado, existe a necessidade de manutenção e evolução contínua de um software, portanto é comum existir alterações ou melhorias em torno deste e uma parte importante do tempo acaba sendo alocada para permitir a continuação de seu ciclo de vida, conforme apontado por Dantas (2013):
Os sistemas de software estão em constante evolução. A manutenção do software, isto é, modificações em artefatos existentes, chega a consumir 75% do custo total do seu ciclo de vida. Aproximadamente, 20% de todo o esforço de manutenção é usado para consertar erros de implementação e os outros 80% são utilizados na adaptação do software em função de modificações em requisitos funcionais, regras de negócios e na reengenharia da aplicação
(DANTAS, 2013, p.1).
Considerando em resumo o que Pressman (2011) aponta, uma equipe de desenvolvimento deve ter uma gestão eficaz das versões do produto para permitir que os desenvolvedores possam retroceder versões anteriores durante o teste e depuração. (DART, 1991, apud PRESSMAN, 2011, p.523) aponta que o controle de versão “captura todas as alterações a todos os arquivos na configuração juntamente com a razão para aquelas alterações e aos detalhes de quem as fez e quando”, permite assim à uma grande equipe de desenvolvedores trabalhar de forma cooperativa.
Dessa forma, percebe-se que os CVSs (Control Version Systems) são de grande utilidade. Contudo, algumas questões que podem surgir para uma equipe de desenvolvimento é: qual sistema de controle de versão escolher? Qual a ferramenta mais usada?
1.2 OBJETIVOS
Para enfocar este trabalho, são definidos aqui o objetivo geral e específicos.
1.2.1 Objetivo Geral
O presente trabalho tem por objetivo, realizar a aplicação prática dos principais controles de versão do mercado de desenvolvimento de software, como forma de servir como uma informação indicadora auxiliar na hora da escolha de uma ferramenta neste enfoque.
20
1.2.2 Objetivos Específicos
Foram estabelecidos os seguintes objetivos específicos: a. Pesquisa das ferramentas de controle de versão;
b. Implementar as principais ferramentas de controle de versão do mercado, apontando as principais características;
c. Comparação analítica entre as ferramentas. 1.3 JUSTIFICATIVA
Um desenvolvimento eficaz e mais consciente é importante, tendo em vista os ganhos gerados com padrões e controles mais rigorosos. Pressman (2011, p.38) afirma que::
Indivíduos, negócios e governos dependem, de forma crescente, de software para decisões estratégicas e táticas, assim como para controle e para operações cotidianas. Se o software falhar, as pessoas e as principais empresas poderão vivenciar desde pequenos inconvenientes a falhas catastróficas. Depreende-se, portanto, que um software deve apresentar qualidade elevada. (PRESSMAN,
2011, p. 38)
Para Sommerville (2007), hoje em dia depende-se de software em diversas esferas e em escala nacional e internacional, sendo que produtos eletrônicos possuem software e as próprias indústrias são automatizadas através de software. O desenvolvimento é por deveras complexo e cheio de alterações. O autor ainda afirma: “Você deve gerenciar sistemas em desenvolvimento porque é fácil perder a rastreabilidade de quais mudanças foram incorporadas em qual versão do sistema.”(SOMMERVILLE, 2007, p.455). Atualmente, no Brasil, existe um projeto que busca disseminar a melhoria nos processos de software, o MPS.BR, que foi criado pela Softex em 2003. Através desse programa foi criado o modelo MPS-SW, que têm referências em modelos e boas práticas internacionais já bastante difundidas. O modelo tem como intuito trazer um manual de referência com boas práticas de engenharia e desenvolvimento de software. Para Konscianski (2007) é muito difícil manter versões de códigos de programas e ainda garantir consistência, ainda segundo o autor, através do controle de versão é possível voltar atrás em alterações realizadas. Segundo Fogel (2003), em projetos de software livre, em que existem vários contribuintes, desenvolvedores podem passar dias buscando bugs e em determinado momento perceber que já foram corrigidos, essa perda de tempo é causada pela falta de atenção ao controle de versão.
Considerando todo o crescente movimento dos últimos anos, de diversas empresas que buscam aprimorar seus processos de desenvolvimento de software, é válido pesquisar conceitos
21 e elaborar conteúdo a fim de explorar essa área em um contexto mais genérico, todavia seguindo os objetivos especificados. Mediante ao grande número de ferramentas gratuitas disponíveis no mercado de desenvolvimento de software, se torna essencial para este trabalho, demonstrar a aplicação de ferramentas de controle de versão e para que este trabalho sirva de referência para futuros trabalhos acadêmicos.
1.4 ESTRUTURA DO TRABALHO
O presente trabalho foi subdividido em seis capítulos. O primeiro capítulo contém a introdução, a problemática levantada, os objetivos gerais e específicos que foram definidos para o trabalho e a justificativa da importância do tema. No segundo capítulo de revisão bibliográfica são trazidos os conceitos relevantes para o trabalho, toda a teoria exposta é derivada de pesquisa bibliográfica, primeiramente é realizada introdução sobre a Gerência de Configuração de Software e em seguida são trazidos os conceitos sobre controle de versão. O terceiro capítulo contém a metodologia utilizada para orientar a realização da pesquisa e os procedimentos deste trabalho. O quarto capítulo de modelagem da solução foi utilizado para trazer a aplicação prática de conceitos implementados por três ferramentas de controle de versão. No quinto capítulo é realizada a análise das ferramentas, baseada nos conceitos pesquisados e no que foi aplicado. No sexto capítulo é realizada a conclusão sobre o que foi aplicado ao trabalho, também são sugeridos neste capítulo trabalhos para serem realizados futuramente.
22
2 REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta o conceito de processo de desenvolvimento de software. Também são mostrados alguns conceitos de gerência de configuração de software, qualidade de software e a forma como estes impactam na criação de um software e os valores agregados com a adoção de tais práticas. Como principal temática do trabalho é apresentado o conceito de controle de versão, suas operações e ferramentas.
2.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE E QUALIDADE
O tema do presente trabalho está incluso na área de tecnologia da informação que possui processos e práticas pertinentes ao desenvolvimento de um produto de software. Sommerville (2007, p.42), traz um conceito bastante sintético sobre o processo de software, que afirma que: “um processo de software é um conjunto de atividades que leva à produção de um produto de software. Essas atividades podem envolver o desenvolvimento de software propriamente dito, usando uma linguagem de programação como Java ou C. “.
No mesmo sentido, segundo Pressman (2010, p.515),
O resultado do processo de software são informações que podem ser divididas em três categorias principais:(1) programas de computador (tanto na forma de código-fonte quanto na forma executável), (2) produtos que descrevem os programas de computador (focado em vários interessados) e (3) dados ou conteúdo (contidos nos programas ou externos a ele). Os itens que compõem todas as informações produzidas como parte do processo de software são chamados coletivamente de configuração de software. (PRESSMAN, 2010, p.515)
Os processos são formados por atividades que proporcionam que o produto tenha os valores necessários agregados durante todo o seu ciclo de desenvolvimento. Para esses procedimentos possuírem atividades bem definidas, é necessário um bom planejamento, que é mais tranquilo ao seguir práticas e conceitos que falam sobre qualidade de software, qualidade em seu processo em todo o ciclo de desenvolvimento. Para Pressman (2011, p.515), a Gerência de Configuração de Software pode ser vista como uma atividade de garantia de qualidade de software aplicadas através de todo o processo.
Um fator importante em um produto de software é sua qualidade. Foram definidas práticas ou padrões que ajudam a definir e manter a organização em todas as atividades que compõem o desenvolvimento do produto. Pressman (2011, p.360) ,define que no sentido mais geral, a qualidade de software pode ser definida como “uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam”. Um produto de qualidade agrega valor ao negócio
23 para o qual é aplicado, baseado nos requisitos especificados. Para Sommerville (2007, p.456), “o gerenciamento de configuração é considerado algumas vezes parte do gerenciamento de qualidade.”
O CMMI (Capability Maturity Model Integration) traz boas práticas para as equipes de desenvolvimento, trabalhando com níveis de maturidade, de modo que cada nível de maturidade é alcançado de acordo com os processos que são praticados. A gerência de configuração também está presente neste manual, que a classifica como um processo de suporte do nível de maturidade 2. O modelo MPS também articula através de níveis de maturidade, neste modelo a Gerência de Configuração de Software está presente no nível de maturidade F. Um processo de software bem definido demonstra que a equipe tem condições de desenvolver bons produtos, parafraseando Pressman, deve ser levada em consideração tanto a visão do cliente/usuário quanto do desenvolvedor.
2.2 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Para Sommerville (2007, p.455), “o gerenciamento de configuração (CM -
Configuration Management) é o desenvolvimento e o uso de padrões e procedimentos para o
gerenciamento de sistemas de software em desenvolvimento”. Pressman (2011), afirma que a configuração é formada pelo conjunto de itens de configuração.
No cenário atual da área de Tecnologia, as empresas e organizações buscam formas de desenvolver mais rapidamente, com mais qualidade e com maior controle. A Gerência de Configuração de Software (GCS) surgiu a partir da necessidade de desenvolver produtos de maneira mais eficaz e produtiva, após a adoção dos padrões de desenvolvimento. A GCS traz mais segurança para gestores, pois sabem que o produto pelo qual são responsáveis seguem padrões que são recomendados, por ter maior confiabilidade e qualidade nos processos do produto. Para Dart (1992, apud Berczuk, 2002, p.1), o “Gerenciamento de configuração de software (GCS) é composto por fatores como identificação, controle de configuração, relatório de status, avaliação, gestão de construção, gestão de processos e trabalho em equipe”.
A GCS serve, pelo menos, à dois propósitos distintos: apoio à gerência e apoio ao desenvolvimento, em relação às atividades de gerência, estão inclusas atividades de identificação de componentes do produto e suas versões, controle de mudanças, status de desenvolvimento, auditoria e revisão. No que diz respeito às atividades de desenvolvimento. Provém funções de controle de versão, em que se permite registrar com precisão a composição
24 dos produtos versionados, além de ajudar a manter consistência entre componentes interdependentes e dispor de recursos para compilar o código e outros artefatos. Ainda discorrendo acerca do apoio ao desenvolvimento, o controle de versão desempenha um papel importante de apoio ao trabalho de equipes de desenvolvimento. Isto porque é um modo que as equipes têm para obter as respostas às perguntas, por exemplo, sobre quem fez alterações recentes?(BERCZUK, 2002)
Dart traz quatro conjuntos de elementos importantes para um sistema de gerência de configuração: elementos de componente, elementos de processo, elementos de construção e elementos humanos.
Elementos de componente - conjunto de ferramentas acopladas em um sistema de gestão de arquivos (por exemplo, um banco de dados) que possibilita acesso à gestão de cada item de configuração de software. Elementos de processo - coleção de ações e tarefas que definem uma abordagem eficaz da gestão de alterações (e atividades relacionadas) para todas as partes envolvidas na gestão, engenharia e uso do software. Elementos de construção - conjunto de ferramentas que automatizam a construção do software, assegurando que tenha sido montado o conjunto apropriado de componentes validados (isto é, a versão correta). Elementos humanos - conjunto de ferramentas e características de processo (abrangendo outros elementos de CM) usados pela equipe de software para implementar uma SCM eficaz. (DART, 2001 apud PRESSMAN, 2011, p.516)
Como acontece para uma ferramenta, que é preciso saber usá-la para executar uma determinada tarefa com precisão e sucesso, assim também ocorre para a GCS. É necessário utilizá-la de maneira que venha agregar para o projeto de desenvolvimento. Quando se implementa um sistema GCS, as seguintes perguntas devem ser respondidas positivamente:
Posso reproduzir exatamente qualquer um dos meus ambientes, incluindo a versão do sistema operacional, com as versões de correção, a configuração de rede, o conjunto de softwares, os aplicativos implementados para o ambiente, e sua configuração? Posso facilmente fazer uma mudança incremental para qualquer um desses itens individuais e implantar a mudança em qualquer um dos meus ambientes? Posso ver facilmente cada mudança que ocorreu a um ambiente em particular e recuperá-la para ver exatamente do que se tratou a mudança, quem o fez, e quando fez? Posso satisfazer todas as normas de conformidade da quais estou sujeito? É fácil para os membros da equipe obterem as informações que eles precisam, e para fazerem as mudanças que precisam fazer? (HUMBLE,2010,p.31,tradução nossa)
2.2.1 Itens de Configuração de Software (SCI - Software Configuration Items)
Os itens de configuração de software segundo Pressman(2011), são as informações geradas a partir do processo de software e pode ser um artefato como um documento ou parte do documento, pode ser um caso de teste dentro de um roteiro inteiro de testes. De acordo com
25 Sommerville (2007,p.458), “planos de projeto, especificações, projetos, programas e massa de dados de teste são normalmente mantidos como itens de configuração.” ainda as informações podem ser programas utilizados no desenvolvimento, scripts de teste, códigos fonte ou documentação de projeto e considerando que toda a configuração muda e evolui ao longo do tempo é importante afirma Sommerville (2007,p.457), “um esquema de identificação consistente para todos os itens no sistema de gerenciamento de configuração”.
2.2.2 Gestão de Mudanças
A gestão de de mudanças é o conjunto de procedimentos que envolvem levantamento de custo das alterações, o impacto e a rastreabilidade sobre as mudanças realizadas Sommerville (2007). Ainda para Sommerville (2007, p.461) “na medida em que componentes de software são alterados, um registro de mudanças realizadas em cada componente deve ser mantido.” Pressman (2011), explica o fluxo da seguinte maneira: primeiramente é realizado uma solicitação para realizar uma alteração, depois é realizado a avaliação técnica para determinar o impacto em relação a outros componentes do sistema e o custo para se realizar a alteração. A avaliação realizada gera um relatório que é passado adiante para a autoridade de controle de alterações, que pode ser formada por uma ou mais pessoas, a autoridade então define a prioridade e os status da alteração. Quando a alteração é aprovada é gerada a ECO (engineering
change order) que contém as informações sobre a alteração assim como as restrições que
devem ser seguidas.
2.2.3 baseline e codeline
Sommerville (2007), diz que baseline é a versão controlada de um sistema e serve como a referência para futuras alterações. De uma maneira resumida, em um processo de desenvolvimento a equipe de desenvolvimento entrega um conjunto de alterações e a equipe de gerência de configuração realiza testes e dependendo do contexto de configuração pode tornar essa versão a baseline do projeto. Pressman(2007,p.517) define que “uma referência é marcada pelo fornecimento de um ou mais itens de configuração de software que foram aprovados em consequência de uma revisão técnica”. A codeline é definida por Berczuk(2002, p.2), como “um conjunto de códigos fonte e outros artefatos que compõem algum componente de software e todas as alterações realizadas ao longo do tempo. A codeline contém cada versão de cada artefato ao longo do caminho”.
26 2.3 DEVOPS
O termo DevOps ganhou bastante espaço nos últimos tempos, na definição de Bass (2015). Trata-se de um conjunto de práticas com intuito de reduzir o tempo entre a realização de uma alteração num produto e a sua liberação em produção, isto sendo realizado também com vistas a garantir qualidade. Como já frisado neste trabalho, a qualidade tem sua importância, por isso a preocupação do DevOps em assegurar agilidade com qualidade. Ainda segundo o autor, é uma resposta para a lentidão na liberação de correções, alterações ou novas funcionalidades. Para ele, “o lançamento de um novo sistema ou a versão de um sistema já existente para os clientes é uma das etapas mais sensíveis do ciclo de desenvolvimento de software” (BASS, 2015, p.38, tradução nossa). Quando um sistema passa a ser usado por mais de uma pessoa, é necessário prestar atenção, pois a cada liberação de uma nova versão abre-se
possibilidade para incompatibilidades ou falhas.
O DevOps exige disciplina da equipe de desenvolvimento. Segundo Sato (2014), equipes de desenvolvimento que implantam as práticas do conceito, devem ter em mente que um processo de entrega começa com um commit em um sistema de controle de versão. O que, ainda, também permite rastrear a origem de problemas em produção. Na concepção de Camargo (2015), em ambientes DevOps, as ferramentas de gerência de configuração centralizam as configurações e facilitam a administração de ambientes com configuração de integração contínua, desde ambientes na nuvem, virtuais ou físicos. No apêndice A deste trabalho é trazido
a montagem de um ambiente de integração contínua.
Através de DevOps é possível: melhorar a experiência dos clientes, aumentar a capacidade de inovar e agregar valor mais rapidamente. Para melhorar a experiência do cliente, é necessário obter e responder continuamente aos seus feedbacks e no mundo de hoje, com sistemas de acoplamento e migração para nuvem, é necessário ter capacidade para reagir e se adaptar de forma ágil, a fim de reforçar a experiência e consequentemente a lealdade por parte do cliente. Quando se fala em aumentar a capacidade de inovar, as organizações modernas utilizam uma abordagem de pensamento, em que se objetiva diminuir o retrabalho e alocar mais recursos para o que gera mais valor e assim, também, busca inovar e resolver os problemas. Sinteticamente falando em aumentar valor de forma mais rápida, quando o DevOps é adotado, fornece ferramentas e culturas que facilitam um planejamento mais eficiente, para liberação, previsibilidade e sucesso. O valor é dependente do contexto da aplicação e da organização, de qualquer forma o objetivo é entregar o valor de maneira mais rápida e eficiente. (SHARMA,
27 2015) Esta conceituação sobre DevOps, reforça a importância dada ao sistema de controle de versão nos meios e fluxos de desenvolvimento e entrega de software atuais.
2.4 CONTROLE DE VERSÃO
Em equipes de desenvolvimento é comum compartilhar artefatos de software entre si, porém com todas as variações é necessário haver um controle das mudanças para o produto em desenvolvimento não ser afetado. Os conflitos de alterações podem acarretar uma série de consequências, que podem acabar gerando mais custos, atraso de entregas. Afirma Pressman (2011):
Se você não controlar as alterações, elas controlarão você. E isso nunca é bom. É muito fácil acontecer de uma sequência de alterações não controladas transformar um bom software em um caos. Como consequência, a qualidade do software é prejudicada e a entrega atrasa. Por essa razão, a gestão de alterações é parte essencial da gestão da qualidade. (PRESSMAN, 2011, p.514).
Um software, pode passar por mudanças que se estendem ao longo de todo os ciclos de desenvolvimento. Identificação e conhecimento do contexto do produto são fatores a serem considerados para começar a criar as estratégias e analisar quais padrões ou técnicas melhor se adequam aos objetos ou processo mapeados. Portanto, é necessário haver controle das mudanças. Segundo Scott (2001, p.6), primeiramente deve-se identificar que itens devem ser controlados, deve-se conhecer o contexto do software, assim como sua configuração e desenvolver uma estratégia baseada na relação e funcionalidade dos itens a serem controlados. Uma ferramenta importante presente em um sistema de gerenciamento de configuração de software, é o controle de versão. A função de um controle de versão é registrar todas as versões de arquivos de software, de modo a facilitar alterações durante o desenvolvimento ou manutenção de um produto. “Desde a década de 1990, existe esse tipo de ferramenta. Alguns exemplos de sistemas de controle de versão mais antigos são CVS, ClearCase, Source-Safe e SVN (que ainda é bastante usado nas empresas).”(AQUILES, 2014, p. 3) Humble explica que: Sistemas de controle de versão, também conhecidos como controle de origem, sistema de gerenciamento de código fonte, ou sistemas de controle de revisão, são um mecanismo para manter múltiplas versões de um arquivo, de modo que quando um arquivo é modificado ainda se pode acessar sua versão anterior. Eles também são um mecanismo através do qual as pessoas envolvidas em um desenvolvimento podem atuar de forma colaborativa em determinada tarefa.(HUMBLE 2010, p. 32, tradução nossa)
Para Sink (2011) a história dos sistemas de controle de versão pode ser dividida em três gerações: A primeira geração de ferramentas, na qual as operações são realizadas apenas
28 localmente, com um arquivo por vez, sem a utilização de um repositório em rede por exemplo; A segunda geração trabalha com um repositório centralizado, as operações podem ser realizadas com múltiplos arquivos. Em compensação a restrição existente é concernente ao merge, que deve ser realizado antes do commit; As ferramentas de terceira geração possuem as funcionalidades de segunda geração, podem trabalhar com repositórios distribuídos e o merge é realizado após o commit.
Pressman (2010) observa que "mecanismos de controle de versão, integrados ao processo de alterações, implementam dois elementos importantes da gestão de alterações - controle de acesso e controle de sincronização". Ainda uma característica importante de um sistemas de controle de revisão é o controle de artefatos que podem ser compartilhados, logo um ou mais desenvolvedores podem alterar o mesmo artefato, o controle pode permitir que cada pessoa tenha a sua versão e que quando for necessário possa sincronizar com a versão principal. Conforme traz o autor:
mecanismos de controle de versão, integrados ao processo de controle de alterações, implementam dois elementos importantes da gestão de alterações - controle de acesso e controle de sincronização. O controle de acesso controla quais os engenheiros de software têm autoridade para acessar e modificar um objeto de configuração particular. O controle de sincronização ajuda a assegurar que alterações paralelas, executadas por duas pessoas diferentes, não sobrescrevam uma à outra. (PRESSMAN,2010,p.524)
O controle de versão é importante durante o desenvolvimento de um produto e útil para evitar conflitos entre o código fonte dos desenvolvedores. Um programador, utilizando um sistema de controle de versão, tem mais facilidade para produzir soluções para determinados problemas sem que cause danos a outras soluções.
É natural que em um projeto de desenvolvimento de software os desenvolvedores do time trabalhem em paralelo no desenvolvimento de funcionalidades e correções. Muitas vezes, podem acabar por alterar os mesmos arquivos gerando conflitos, ou até mesmo, alterar arquivos diferentes, que depois de combinadas as alterações, o software apresente um comportamento inadequado. De qualquer forma, de tempos em tempos, as alterações precisarão ser integradas em uma base comum de código. (GOMES, 2013, p. 81)
Os sistemas de controle de versão trabalham com o conceito de repositório, onde os artefatos de um software, assim como todas as suas versões, são mantidos. O repositório pode ser definido como:
29 [...]uma biblioteca centralizada de arquivos que estão sob o controle de versão. A noção de repositório foi inicialmente proposta com o Revision Control System (RCS) que foi desenvolvido por Walter F. Tichy. Todas as informações de CM sobre arquivos e o conteúdo desses arquivos são mantidas no repositório. (PRADO, 2006, p.11)
De acordo com o esquema de repositório os sistemas podem ser classificados como centralizados ou distribuídos. A seção 2.4.1 discorre sobre os sistema centralizados e distribuídos.
2.4.1 Sistema Centralizado e Sistema Distribuído
O controle de versão nasceu da necessidade de vários desenvolvedores poderem integrar seus códigos de forma coesa e segura, a primeira abordagem se deu com o paradigma de controle de versão centralizados (Centralized Version Control System ou CVCS). Segundo Chacon(2014), esses sistemas possuem um único repositório central, onde estão todos os arquivos versionados, um cliente pode resgatar (fazer um check out) os arquivos do servidor. Essa abordagem oferece muitas vantagens, uma delas é que toda a equipe de desenvolvimento pode saber o que os seus colegas estão fazendo, outro ponto é o controle de acesso por parte dos gestores, que podem dar acesso a partes específicas do projeto, não permitindo que o desenvolvedor ou qualquer outra pessoa interfira em um artefato alheio sem a devida autorização (CHACON, 2014). Chacon (2014), relata que um sério problema nesse tipo SCV é que, como todo o código e histórico fica centralizado, esse se torna o único ponto de falha, então na ocorrência de qualquer problema com o repositório principal, os usuários param de trabalhar em conjunto ou salvar novas versões e se o disco do servidor for corrompido todo o histórico de alterações e versões é perdido.
Os sistemas de controle de versão distribuídos são sistemas que operam com redundância de repositórios, enquanto no centralizado se trabalha com apenas um repositório central, em sistemas distribuídos segundo Chacon(2014) cada desenvolvedor é um nó e um distribuidor dentro do fluxo de trabalho, sendo assim “cada usuário mantém um repositório autocontido, de primeira classe, em seu computador” (HUMBLE, 2014, p.397). Quando se há a necessidade de se realizar uma alteração, é possível realizar no ambiente local e depois de efetuada replicar ao repositório principal (FREITAS, 2010). Neste formato o repositório não corre tantos riscos, caso os desenvolvedores mantenham seus repositórios locais sempre atualizados com o principal, segundo O’Sullivan (2009) se houver uma falha ou uma perda de
30 dados no repositório principal, as informações podem ser recuperadas de um dos repositórios locais, pois cada um dos colaboradores possui um backup em seu computador local.
2.4.1.2 Repositório Remoto e Desenvolvimento Colaborativo
Na realidade dos projetos de sistemas atuais, o uso de repositório remotos é quase indispensável. O’Sullivan (2009) diz que os serviços de hospedagem de repositório como o Bitbucket, por exemplo, quando bem projetados, realizam todo o trabalho relacionado aos protocolos de segurança, controle de acesso e ainda permitem que os usuários se comuniquem. Neste cenário segundo Chacon (2014) quando os repositório são públicos, os usuários podem realizar o clone do projeto, os serviços de hospedagem atuais permitem ao mantenedor do projeto integrar outras ferramentas para realização de testes e envio de alterações. Por fim é interessante o que Swicegood traz:
Compartilhar seu trabalho com outros desenvolvedores significa que será necessário um repositório remoto. A maneira mais fácil de trabalhar com um repositório remoto é clonar um repositório existente. A clonagem cria uma cópia local do repositório remoto. Para os projetos que já estão em andamento, esta é a rota normal, mas não é o única. Um repositório remoto pode ser configurado mais tarde, se inicialmente um desenvolvedor começar a trabalhar em um projeto sozinho e em seguida, precisar compartilhá-lo. (SWICEGOOD, 2007, p.113)
O uso de repositório remoto é suportado por sistemas distribuídos e sistemas centralizados. Considerando conforme Humble(2014), às possibilidades oferecidas pelos serviços como GitHub, Bitbucket facilitam para que desenvolvedores compartilham códigos ou projetos com outros desenvolvedores, essa estrutura ainda permite que os usuários que tenham interesse colaborem com um projeto e também compartilhem suas alterações ou melhorias de forma fácil, rápida e segura.
2.4.2 TRUNK, BRANCHING E MERGING
Em um sistema de controle de versão existe a versão principal, que pode ser chamada de main line, que em tradução livre é linha principal ou ainda simplesmente chamada trunk, essa versão principal de desenvolvimento, se estiver falando em software, contém o conjunto com as principais funcionalidade do que se está desenvolvendo. O branch é um termo em inglês que significa ramo, é uma linha de referência do código de uma aplicação. O branching é um
31 dos recursos essenciais em sistemas de controle de versão, pois permite que sejam criadas cópias dos códigos de uma determinada versão de um software. Humble traz que:
Essa operação cria uma réplica de uma revisão escolhida dentro do controle de versão. Essa réplica pode então ser manipulada da mesma forma (mas independentemente) como a revisão original e permite que elas sejam divergentes. O propósito principal de branches é suportar o desenvolvimento paralelo: a capacidade de ter duas ou mais linhas de trabalho ao mesmo tempo sem que uma afete a outra. (HUMBLE, 2014, p.392)
O modelo de branching é simples, é uma espécie de versão desenvolvida em paralelo com a principal, esta é uma das principais maneiras de se trabalhar quando se tem necessidade de desenvolver uma nova funcionalidade e esta funcionalidade necessita de todas as demais funcionalidades. Outros diversos motivos levam a criação de um ramo, podem ser físicos, funcionais, ambientais, organizacionais e processuais. A adoção de um branch permite, por exemplo, utilizar a estratégia de esconder novas funcionalidades enquanto não ficam prontas e são entregues. (HUMBLE, 2014)
Quando é necessário replicar uma alteração de um branch para outro, é necessário realizar a operação chamada merge. No merge dois ramos são sincronizados, mas a sincronia pode ser total ou apenas parcial, dependendo se for apenas para adicionar uma funcionalidade ou um arquivo recém criados, ou então tornar o conteúdo dos dois branches iguais. Os dois
branchs são independentes, portanto podem ter ocorrido alterações em um branch que sobrepõe
alterações em outro branch. Nesse ponto os ramos trazem problemas relacionados a sincronização das alterações. Atualmente, ainda de acordo com Humble (2014), os sistemas de controle de versão realizam facilmente operações de merging, mas se houver os chamados conflitos de alterações, os sistemas ficam sem uma solução para dar. O fator humano é preponderante para se resolver estes conflitos, mas quando são muitos os conflitos, problemas, podem ocorrer. De forma a tentar amenizar Humble recomenda:
criar branches que serão mantidos por um bom tempo somente para a entrega de versão [...] Nesse modelo, qualquer novo código sempre é criado no trunk. Um merge ocorre apenas quando precisa ser feita uma correção em um dos branches já entregues, a partir do qual também é portado para o trunk. Correções crı́ticas também podem ser portadas do trunk para um dos branches. Esse modelo é melhor, porque o código sempre está pronto para ser entregue, e as entregas são consequentemente mais fáceis. Há menos branches e, portanto, menos trabalho a ser feito em merges e controle dos branches. (HUMBLE, 2014, p.396)
A recomendação ajuda a evitar problemas com os merges e perda de tempo com a resolução dos problemas; agiliza a entrega da aplicação para ser implantada. O branching e o
32
merging são recursos que necessitam de políticas, disciplina e bastante cuidado das equipes de
desenvolvimento.
2.4.3 Operações e Conceitos comuns dos sistemas de controle de versão
Existem conceitos e operações que são comuns para a maioria dos sistemas de controle de versões atuais. De acordo com Sink (2011), existem operações básicas ou conceitos, que podem ser implementados em um sistema de controle de versão, cada sistema implementa a sua maneira dentro de sua estrutura.
2.4.3.1 commit
O processo de commit, tem por função acometer as mudanças, que foram realizadas em um arquivo para o seu respectivo repositório, ainda, de acordo com Fogel (2007), é armazenar formalmente uma alteração no banco de dados do sistema de controle de versão. Ainda cada commit pode carregar uma mensagem chamada de log message, que serve para informar o motivo da operação. Sato (2014, p.129) afirma que o commit “agrupa os arquivos alterados com o autor da mudança e uma mensagem explicativa. Isso permite que você navegue no histórico do projeto e saiba quem mudou o quê, quando e porquê”.
2.4.3.2 pull or update
Conforme Fogel (2007), no processo de update ocorre a atualização do projeto local, de modo que as mudanças que foram incorporadas pelos commit de outros usuários ao repositório, são incorporadas para a cópia de trabalho local. Para Sink ( 2011), a operação atualiza a cópia de trabalho local, aplicando as alterações provenientes do repositório e realizando merging com as alterações realizadas na cópia de trabalho, quando existirem alterações.
2.4.3.3 push
Na compreensão de Folger (2007), a operação de push se dá através do repasse de alterações, do repositório local, onde os commits foram realizados para um repositório principal. Nos sistemas distribuídos, as alterações são submetidas para atualizar um repositório remoto. Nos sistemas centralizados, a operação de commit já replica as alterações para o repositório principal.
33 2.4.3.4 checkout e cópia de trabalho
Segundo Fogel (2007), o checkout é o processo de se obter uma cópia de um projeto a partir do repositório onde ele se encontra, a cópia criada é chamada de cópia de trabalho, que é uma árvore de diretórios e que contém todos os arquivos e metadados necessários para que, através do controle de versão, sejam realizadas todas a operações necessárias para se manter a sincronia com o repositório.
2.4.3.5 merge
A operação de merge é a fusão de dois branches de desenvolvimento. Para Sink (2011) é a convergência dos ramos de desenvolvimento que estão divergentes e a mesclagem através de um sistema de controle de versão torna a operação mais simples.
2.4.3.6 resolve
Sink (2011) afirma que em alguns casos o merge automático não pode resolver conflitos existentes entre branches, neste caso a prática de resolução de conflitos confere responsabilidade ao usuário humano, seja manipulando manualmente um arquivo ou informando como o SCV deve prosseguir.
2.4.3.7 lock
No entendimento de Sink (2011) a operação lock é a obtenção de exclusividade para alterar um arquivo. Ainda afirma que, é mais eficiente deixar a cargo do SCV, o gerenciamento da concorrência em arquivos de texto simples e para arquivos binários, que são mais complexos é útil a utilização do lock. Collins-Sussman (2008) diz que a operação deve “permitir que um usuário requeira programaticamente o direito exclusivo de modificar um arquivo no repositório” e que também é “um mecanismo para exclusão mútua entre os usuários para evitar submissões conflitantes.” (COLLINS-SUSSMAN, 2008, p. 54)
34 2.4.3.8 tag
Sink (2011) afirma que a tag é a marcação de um momento específico do repositório, ou do projeto com um rótulo significativo. Para Bar (2003) é a associação de um evento em um momento específico, possibilitando assim, recuperar o projeto como ele era no momento rotulado.
2.4.3.9 log
Considerando que um sistemas de controle de versão armazena e mantém no repositório as alterações, ou operações já realizadas. O log seria a operação que permite visualizar o registro dessas operações Sink (2011). O log “irá acompanhar a história e evolução do seu projeto[...]Para cada mudança, você terá um registro de quem a fez; porque a fez; quando fez;o que foi alterado” (O’SULLIVAN, 2009, p.2,tradução nossa)
2.4.3.10 create
“A operação create é usada para criar um novo repositório.[...]Quando você cria um novo repositório, seus SCV vai esperar que você diga algo para identificá-lo, tal como onde você quer que ele seja criado, ou qual nome deve ser utilizado.” (SINK, 2011, p.5)
2.4.3.11 add
A operação de adição em controles de versão é utilizada para indicar arquivos ou diretórios que devem ser adicionados ao repositório. Conforme explica Sink (2011), a operação de adição é utilizada quando se tem um arquivo ou diretório que ainda não está sob controle de versão e deseja adicionar ao repositório. Ainda complementa que a adição não é realizada imediatamente, ela é adicionada ao conjunto de alterações da cópia de trabalho.
2.4.3.12 edit
A edição de arquivos não é uma funcionalidade direta do SCV, Sink(2011) o usuário altera um arquivo como qualquer outro de seu sistema de arquivos e cabe ao SCV reconhecer que o arquivo foi editado e adicionar essas alterações ao conjunto de alterações.
