Esta é a última parte desta série sobre o Jenkins e é também onde justamente tudo aquilo ensaiado na parte anterior será efetivamente colocada em prática com a criação de um job contendo várias etapas, com execução disparada por um outro e, para encerrar algo mais complexo que o Freestyle Project, a execução em pipeline.
Então é iniciar a máquina virtual com vagrant up para começar a usá-lo.
A primeira parte consistiu basicamente em instalar e deixar o Jenkins minimamente configurado e, claro, funcionando. A parte de acesso a usuários permite usar diversos modos de autenticação (LDAP, usuários locais etc) enquanto os plugins consistem quase que em um universo a parte dentro do Jenkins.
Agora será a vez de efetivamente utilizá-lo para a criação de alguns build jobs, um primeiro para meramente testar o funcionamento da ferramenta e um outro cuidando de monitorar alterações no repositório do código fonte e se encarregar de compilá-lo.
Por padrão os repositórios web do Git usam o protocolo HTTPS tanto para a transferência de arquivos — nos comandos clone, pull, push etc — como para a autenticação dos usuários — quando do push e do clone e pull nos repositórios privados.
A “chatice” deste método é precisar (lembrar e) ficar digitando a senha para estas operações. Mas tanto BitBucket, GitHub quanto GitLab disponibilizam também a autenticação de usuário no repositório por SSH e é algo tão simples de configurar que vale a pena fazê-lo…
…nem que seja para fugir de uma vez da digitação da senha. 🙂
A partir deste ponto o fluxo de trabalho do Git já deixou de ser novidade; assim como também o utilizar branches, recuperar arquivos de commits anteriores e até indicar à ferramenta como ignorar determinados arquivos no diretório de trabalho. Agora é chegada a hora de utilizar o Git para o propósito ao qual ele foi desenvolvido, ou seja, o compartilhamento do repositório para permitir o trabalho distribuído. 🙂
Na primeira parte foi apresentado o fluxo de trabalho e alguns conceitos básicos do Git, na segunda foi a vez de acrescentar o branch e também a “arte” de trazer arquivos de commits passados. Porém até o momento tivemos “sorte” em inserir os arquivos corretos e na hora certa dentro do repositório mas o que fazer quando algo dá errado e é necessário mexer na index ou mesmo da HEAD para corrigir o problema?
Nota : No meu planejamento nesta parte deveria ser a vez de tratar dos repositórios remotos e só me dei conta de que faltava isto aqui quando a parte dois já havia sido publicada… 
A primeira parte foi basicamente um exercício do fluxo de trabalho do Git, ou seja, criar/editar um arquivo no working directory, colocar na staging area e então enviar para a HEAD. Mas eu dissera que o conceito é importante, não foi?
Agora é vez de acrescentar mais alguma complexidade com a introdução do conceito de ramificação nos repositórios.
