Gerência de Configuração

Este documento tem por objetivo documentar toda a estratégia de backup utilizada pela Basis, bem como estabelecer critérios de backup e evidenciar a realização da prática através de relatórios, apontando problemas e correções.

Considera-se no escopo deste documento abordar todas as etapas e procedimentos que são necessários para a construção efetiva de um backup, tal como as configurações e breves explicações sobre o funcionamento de ferramentas envolvidas.

Estão fora do limite definido como escopo deste documento dados de máquinas cujo backup é realizado pelas ferramentas listadas, informações inerentes à configuração e conexão da VPN da Basis, bem como de acesso remoto à máquina do Bacula, ou especificidades desnecessárias ao contexto.

O Director (bacula-dir.conf) é a parte mais complexa do sistema, em que se figura toda a configuração dos trabalhos de backup (job), agendamentos, pools, seleção dos alvos de backup (FileSet), definição do tipo de armazenamento, etc. Em suma, configuram-se os clientes e arquivos que farão parte do backup, além de realizar a comunicação entre os clientes e dispositivos de armazenamento.

File Daemon (bacula-fd.conf). Todos os clientes que possuem esse daemon em execução estabelecem uma comunicação com o Director, que por sua vez gerencia todas as máquinas e redireciona os dados destas para o Storage.

Storage Daemon (bacula-sd.conf) é o arquivo de configuração do Bacula, em que se relacionam os dispositivos de armazenamento, como fitas e discos, para organizar os dados armazenados advindos do Director. Esse agente estabelece a comunicação com tais dispositivos, armazenando ou recuperando os arquivos específicos de cada cliente.

Os commits deverão obedecer a seguinte regra:

Onde: * XXX - é o número da ocorrência no SGO;

Perfis: Analista de Qualidade, Gestor de Contratos/ Preposto, Gerente de RH, Assistente de RH, Auditor de Configuração, Analista de Configuração, EPG, Responsável por Medição e Análise, Analista Financeiro, Entrevistador.

Perfis: EPG, Analista de Qualidade, Responsável por Medição e Análise

Perfis: Analista de Configuração, Auditor de Configuração.

Perfis: Analista de Configuração, Auditor de Configuração, Assistente de RH.

Perfis: Gestor de Contratos/ Preposto

Os itens de Melhoria são armazenados em um repositório próprio: Projeto de Melhoria

A pasta de Estatísticas é dividida por Baselines, sendo que cada nova Baseline terá uma pasta específica associada.

A partir da Baseline BASIS_BL_ORG_06, a Biblioteca é inteiramente elaborada em AsciiDoc e publicada no site http://foundation.basis.com.br.

Todos os itens da Biblioteca de Ativos têm controle formal e são obrigatórios.

O software TortoiseGit é uma de várias possíveis interfaces gráficas para Git no Windows. Ele pode ser baixado em sua versão mais recente no site: https://tortoisegit.org/download/. Para que o TortoiseGit funcione corretamente, faz-se necessária a instalação do Git for Windows, no site: http://git-scm.com/download/win. Apenas após a instalação do mesmo, o TortoiseGit deve ser instalado. Atenção à versão baixada (32-bit ou 64-bit), que deve obedecer às especificações da sua máquina para as duas instalações.

Usando o Windows Explorer, na pasta onde se deseja manter o repositório local, clica-se com o botão direito. No menu de contexto, a opção "Git Clone" deve ser selecionada.

Na janela que segue, no campo URL, deve ser colado o link de clone copiado da página de repositório do Gitlab. Se o link já estiver previamente copiado, deve aparecer automaticamente no campo.

Da primeira vez que se faz qualquer operação num repositório, o TortoiseGit exige informações de usuário. Basta colocar o nome de usuário e e-mail Basis, e clicar em OK.

O nome de usuário e a senha da rede devem ser digitados para validar o clone.

Os mesmos ficarão salvos no Gerenciador de Credenciais do Windows, caso precisem ser alterados.

Após a confirmação da senha, uma tela será exibida informando o progresso do clone.

Ao concluir, o repositório já estará localmente replicado na máquina do usuário.

O Git oferece a opção de clone dos repositórios via HTTPS, como já foi apresentado, ou via SSH. O SSH costuma ser mais prático e menos limitado que o HTTPS, mas necessita de várias configurações locais e remotas para funcionar devidamente.

Inicialmente, deve ser gerada uma chave SSH localmente na sua máquina. Para tanto, vamos usar a interface padrão de console do Git for Windows, que também serve como alternativa ao próprio TortoiseGit, se for mais interessante usar comandos de linha diretamente em vez de uma interface gráfica.

Na máquina local, buscar, no menu Iniciar ou na barra de buscas do Windows, o programa Git Bash. A janela inicial será um console em preto:

Digitar o seguinte, e pressionar Enter:

O console vai pedir, na ordem:

Acessando o caminho da chave no Windows, devem haver dois arquivos: id_rsa e id_rsa.pub. O segundo deve ser aberto em qualquer editor de texto, para que se possa copiar a chave.

Com a chave em mãos, entrar no Gitlab, e adentrar a seção "Configurações", no menu do canto superior direito.

Ali dentro, selecionar no menu esquerdo "Chaves SSH". Na seção que se abrir, colar a chave do id_rsa.pub, dar um título para identificar a chave, então clicar no botão "Adicionar Chave" abaixo.

Feita a adição com sucesso, a última coisa que precisa ser feita é uma alteração local do programa utilizado para SSH no TortoiseGit. No menu iniciar ou de busca, procurar por Settings, um programa que tenha o ícone do TortoiseGit. Entrando no mesmo, selecionar o item Network no menu esquerdo. Ali dentro em SSH, basta colocar o caminho do executável SSH do Git for Windows (por padrão, C:\Program Files\Git\usr\bin\ssh.exe, variando o início do caminho de acordo com a sua pasta de instalação) e clicar em OK.

Feito isso, operações de repositório já podem ser realizadas usando SSH. Basta fazer o clone do repositório utilizando o link SSH que o mesmo fornece na página do repositório.

Dentro da página no Gitlab do repositório que se deseja copiar, clicar em Fork, no canto superior direito.

Selecionar como namespace o próprio nome de usuário, apresentado por padrão na página.

O repositório será criado e toda a estrutura de commits passará por uma importação. Uma vez finalizada, o repositório apresentará a mesma exata estrutura que o original. Desse ponto em diante, as ações de clone e push seguirão os mesmos princípios já apresentados.

Para que o código atualizado no fork seja replicado no repositório original, é necessário que seja aberto um merge request a partir do fork, apontando para a branch do repositório original. Esse merge request precisa ser aberto por um usuário que tenha acesso de escrita no repositório original, e é necessário que haja mais de um commit para o merge, pois será realizado um git squash. Caso seja aberto pelo próprio dono do Fork, que possui acesso somente leitura ao original, ou caso possua apenas um único commit, será fechado imediatamente pelo próprio sistema.

Na tela do repositório fork, no menu esquerdo, clicar em "Merge Requests".

Dentro da tela, haverá um botão "Novo Merge Request". Selecionando o mesmo, será aberta uma nova tela para seleção de quais branches e repositórios servirão como origem e destino. Para origem ("Source Branch"), selecionar o seu fork e a branch onde se trabalhou. Para destino, selecionar o repositório original, e a branch do mesmo onde o merge deverá ser feito. Clicar em "Compare branches and continue".

Na tela que se segue, escrever um título para o seu merge request, preferencialmente incluindo a ocorrência relativa aos commits em questão para que esteja na mensagem de squash. Adicionar também uma descrição, que será unida ao template de MR da Basis, quando aplicável. No campo Assignee, apontar um usuário responsável pela aprovação do MR, caso necessário. A opção "Delete source branch when merge request is accepted" apagará a branch original do fork assim que houver o merge de fato. E a opção "Squash commits when merge request is accepted" será marcada automaticamente, mesmo que seja desmarcada nesta tela.

Uma vez criado, o merge request será listado no menu de Merge Requests do repositório original.

Também será criado um link para acessar o merge request na ocorrência do SGO mencionada pelo mesmo.

Quando aprovado e selecionada a opção Merge, será realizado um commit de squash combinando os commits do repositório de fork, mais um commit de merge mesclando os dois repositórios. O código então será disponibilizado na branch do repositório original. Se houver algum problema no merge ou na criação do próprio merge request, o próprio sistema informará em mensagem.

Quando o fork se encontra atrasado em relação ao repositório original, é possível atualizá-lo em seu repositório fork clonado localmente. Para isso, é necessário inicialmente adicionar o repositório original como um novo remote caso não exista, executando no seu repositório local o seguinte comando:

Atualiza-se então esse remote "upstream" usando um fetch:

Para sincronizar de fato seus arquivos locais com os do repositório original, realiza-se um merge do seu repositório local, usando como base a branch requisitada do original (por padrão, "master"; alterar de acordo):

Por fim, para atualizar o repositório no Gitlab, realiza-se o push padrão:

Verifique, antes de tudo, se seu repositório local está atualizado. Diferente do SVN, não basta que apenas a pasta específica em que se está editando esteja devidamente atualizada; o repositório inteiro deve estar em dia. Realize sempre um Pull antes de fazer quaisquer modificações.

Se o repositório não estava atualizado, mas o commit foi feito ainda assim, realize um Pull de todo modo. Pode ser que não haja conflitos de arquivos modificados. Se for o caso, o Pull não retornará erros, não haverá ícones de conflito nas pastas, e o seu Push pode ser realizado diretamente em seguida (sem o commit, nesse caso, pois este já havia sido feito).

Entretanto, se houver conflitos, cabe verificar com a sua equipe se os arquivos em questão foram modificados. O próprio Log do Git deve retornar informações sobre quais foram as últimas modificações sobre o determinado arquivo, o que pode ser verificado clicando sobre o mesmo com o botão direito e selecionando, sob o menu do TortoiseGit, Show Log.

A janela seguinte terá informações de quais foram os últimos commits, e quem os realizou, para devida informação e discussão.

Uma vez que se tenha certeza que o arquivo existente no seu repositório local é o mais atualizado, deve-se selecionar, no menu do TortoiseGit na pasta, a opção "Resolve".

Marca-se então os arquivos atualizados, confirma, e então o Commit/Push pode ser realizado novamente com maior segurança.

Se ainda houver erro, experimente executar um Clean up, opção logo acima também representada. Execute também um novo Pull em seguida, para poder realizar o commit depois com segurança, e certifique-se de que todos os arquivos estão presentes no repositório local.

Para corrigir essa situação, é necessário emendar à mensagem do commit uma ocorrência válida do SGO. Se apenas um commit errôneo foi realizado, basta selecionar Git Commit novamente no repositório em questão e selecionar a opção Ammend Last Commit na caixa logo abaixo da entrada de mensagem:

Em seguida, clicar em Ok e seguir com o mesmo modelo de Commit/Push apresentado mais acima.

Se houver mais de um commit na fila, no entanto, e até mesmo em outros casos de erro recorrente, será necessário fazer um Rebase, ou refazer os commits do zero antes de realizar o Push.

Quando um commit é feito no Git, ele se mantém na fila para subir ao repositório remoto num Push. Outros commits em cima do mesmo apenas se acumulam na fila. Ou seja, se o primeiro commit está errado, ele permanecerá sem enviar para o sistema até que seja removido ou editado na fila. Nesse caso, como existem vários commits errados na fila, a procedência possível seria editar ou eliminar a mesma.

Para o primeiro caso, o chamado Rebase, clicar com o botão direito na pasta do repositório com os commits problemáticos, e dentro do menu do TortoiseGit, selecionar a opção Rebase.

Na janela que segue, marcar inicialmente a opção Force Rebase, para que o sistema leve em conta todos os commits diferentes entre o repositório local e o remoto. Em seguida, clicar com o botão direito no commit que está com problemas (pode ser mais de um), e selecionar a opção Edit. Feito isso, iniciar o Rebase através do botão Start Rebase no rodapé da janela.

Uma vez iniciado, se configurado corretamente, ele vai parar para edição da mensagem do(s) commit(s) em questão. Adicionar a ocorrência faltante, e clicar em Ammend, e em seguida em Done.

Terminado o processo de Rebase, o Push já pode ser feito sem a necessidade de fazer um novo commit.

Para o caso de refazer a fila de commits do zero, primeiramente, é interessante fazer um backup dos arquivos alterados em tais commits, pois serão apagados ou substituídos pelas versões atualmente presentes no repositório remoto. Com o backup feito, selecionar na pasta raiz do repositório: TortoiseGit > Switch/Checkout. Na janela aberta, deixar exatamente como está na imagem abaixo, com todas as marcações (ênfase na branch remote/origin/master do primeiro menu, não é a master originalmente selecionada).

Após clicar em OK, o repositório retornará ao seu estado anterior aos commits errôneos, exatamente igual ao repositório online. Com isso, os arquivos no backup podem ser copiados de volta para a pasta do repositório, e o commit pode ser refeito.

Se houver mais erros, entre em contato com a gerência de configuração.

É possível que o repositório em questão tenha nomes de arquivos ou caminhos muito grandes e, quando se realiza um Clone do mesmo num sistema Windows, ele não consiga abranger todo o caminho, retornando erros de Filename too long. Se for esse o caso, experimente realizar o Clone em outra pasta do seu sistema, preferencialmente alguma num caminho bem curto, como C:\git.

Outro erro possível teria a seguinte mensagem: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. Nesse caso, é necessário atualizar os protocolos de conexão SSL na configuração do Git para uma versão mais segura. Execute o seguinte comando no Git Bash (para seu uso, consultar a seção de SSH):

Após essa alteração, o Clone/Pull deve funcionar corretamente. Caso contrário, ou se o comando retornar algum erro, é recomendável reinstalar o Git numa versão mais recente.

Se tais soluções não funcionarem, ou se o erro for diferente, entre em contato com a gerência de configuração.

Este documento objetiva apresentar todos os passos necessários para que os interessados em realizar a criação de um novo repositório sejam capazes de, seguindo as instruções, chegarem ao resultado esperado, de uma forma correta e padronizada.

Considera-se no escopo deste documento abordar todas as etapas e procedimentos, que são necessários para a criação efetiva de um repositório remoto, englobando desde a conexão com a máquina até o commit inicial com a estrutura de pastas padrão de novos projetos da empresa.

Está fora do limite definido como escopo deste tutorial as informações inerentes à configuração e conexão da VPN da Basis, bem como de acesso remoto aos servidores internos.

A princípio, nenhum repositório de sistema deve ser criado sem uma ocorrência do tipo Tarefa com essa requisição, encaminhada para o departamento de Configuração. Para iniciar a criação, basta entrar nessa ocorrência, e na aba Dados do Sistema, clicar na ocorrência repassada em "Ocorrências do Sistema".

Dentro da ocorrência do sistema, nas transições de fluxo de trabalho, selecionar a transição "Criar Repositórios".

Uma janela pop-up deve aparecer na ocorrência, com os dados do sistema e campos para especificar quais repositórios serão criados. Caso nada seja escrito, por padrão, e seguindo o Guia de Gerência de Configuração, são criados os repositórios "codigo_fonte", "documentacao" e "gravacoes". O nome do sistema é preposto ao nome de cada repositório, ou seja, caso se escreva "backend", o nome do repositório será "sistema_backend".

Os repositórios por padrão são criados usando a estrutura padrão estabelecida para cada tipo de repositório, tendo um commit inicial apropriado. Entretanto, caso o repositório precise ser migrado de algum cliente e o projeto precise ser criado vazio, basta marcar o campo "Repositórios Migrados do Cliente". Todos serão criados sem qualquer commit, ficando a responsabilidade de popular o repositório para quem for importar o projeto do cliente.

A transição desencadeará as seguintes ações via webhook:

Finalizada a transição, os repositórios serão listados ao fundo aba Cadastro do Sistema, juntamente ao grupo relacionado no AD.

Caso também exista, requisitado via tarefa no SGO, um pedido para associar usuários específicos aos repositórios, é necessário realizar outra transição. Dentro da ocorrência do sistema, nas transições de fluxo de trabalho, selecionar a transição "Associar Usuários a Repos".

A janela da transição apresentará dois campos para preenchimento, sendo um para usuários que terão acesso de escrita e outro que terá usuários cujo acesso será de somente leitura. Preencher com o nome de usuário de cada um, separado com vírgulas (o próprio sistema auxilia auto-completando nomes), e realizar a transição.

Realizado este passo, os usuários serão associados ao grupo relativo ao sistema no AD Basis. Um serviço periódico de sincronização de usuários, executando em paralelo ao Gitlab, será responsável por associar esses usuários também aos repositórios do próprio Gitlab. O acesso, portanto, não é imediato, mas deve ser atualizado em menos de uma hora. A lista de usuários com acesso pode ser visualizada na seção Pessoas, à direita da ocorrência do sistema, no campo "Equipe Git".

Adicionalmente, existem grupos no AD cujos membros possuem acesso a todos os repositórios do cliente (“nomecliente_all” para escrita e “nomecliente_all_ro” para leitura). Caso haja requisição no SGO para acesso a todos os repositórios de determinado cliente, o acesso precisa ser dado diretamente nesses grupos, a partir do gerenciamento de usuários do próprio SGO ou do AD.

Na tela do Sistema de Gestão de Ocorrências (SGO) da Basis, acessar o menu no topo esquerdo da tela, e selecionar "Repositório Git", ou acessar diretamente o link https://gitlab.basis.com.br/. Se o login já estiver realizado via SSO no próprio SGO, o acesso será automático. Do contrário, a tela de login será apresentada. As credenciais de acesso são as mesmas do SGO.

Na página inicial após o login, clicar em "Grupos" para visualizar os clientes disponíveis e selecionar o desejado que receberá o novo repositório. Caso seja um novo cliente, clicar no botão "Novo Grupo" acima dos existentes.

Entrar com a chave do cliente, atribuir um avatar e editar a URL se necessário. Vale constar que a chave por padrão é a mesma usada na alocação do contrato no SGO, e não pode conter espaços ou caracteres especiais. Além disso, o nível de visibilidade deve ser marcado como Privado.

Na tela do grupo, no canto direito da tela, clicar em "Novo projeto".

Entre com o nome que o repositório receberá, seguindo o padrão:

Vale constar que o nome não pode conter espaços ou caracteres especiais.

Uma vez criado, o projeto terá as configurações padrão do sistema aplicados a si. Salvo exceções especificadas pelos próprios gestores e clientes, não é necessário alterá-las. Contudo, essas mesmas configurações impedem que equipes possam fazer alterações nos repositórios se não houver uma branch inicial, portanto faz-se necessário criar um primeiro commit.

Dentro do próprio Gitlab, é possível já criar um único arquivo de commit para base do repositório. No projeto vazio, clicar em Novo Arquivo.

Preencher o caminho do arquivo com o seguinte nome:

Preencher o conteúdo do arquivo com o seguinte texto:

Por fim, preencher o campo de mensagem de commit, substituindo a chave de ocorrência pela chave relativa à Tarefa de criação do repositório, ou sistema associado:

Estando tudo de acordo, como na imagem, clicar em Commit abaixo. O arquivo estará então aplicado ao código, permitindo commits da equipe e merge requests seguindo o padrão Basis.

A partir do Gitlab, clonar o novo repositório de documentação seguindo as instruções de Como efetuar o clone do Manual de _Git.

Dentro da pasta local clonada do repositório vazio, colar e executar o arquivo: mkdirsgit.bat (ou mkdirsgit.sh caso o sistema seja Linux).

Se o script rodou corretamente, a pasta agora possui oito novas pastas na sua raiz. Apagar ou mover para fora o arquivo mkdirsgit.bat ou mkdirsgit.sh.

Clicar com o botão direito na pasta raiz do repositório e selecionar "Git commit → master…​".

Se surgir uma mensagem informando que o nome de usuário e E-mail precisam ser setados, clicar em Yes, preencher o formulário seguinte com seu nome de usuário e E-mail Basis, selecionar "Save as Global" e clicar em Ok.

Marcar todos os arquivos da lista (vários .gitignore para manutenção das pastas), comentar e executar o commit.

Mensagem de commit sugerida:

Quando finalizar o commit, clicar em Push logo abaixo.

Clicar em OK, digitar sua senha e aguardar a finalização.

Ao terminar de enviar o push, o repositório estará configurado e já poderá receber os documentos do sistema.

Caso um commit ou push dê errado, faz-se necessário realizar um Pull para manter o repositório local atualizado e estável. Clicar com o botão direito na pasta raiz do repositório e selecionar "Git Sync…​".

Na janela resultante, selecionar Pull. Entrar com sua senha e aguardar a finalização.

Nessa janela, também é possível realizar commits e pushes, se for conveniente. Lembrando que, após o pull, o push deve ser executado novamente. Um novo commit não é necessário, exceto se tiver conflitos em arquivos do repositório que precisem ser resolvidos.