Tutoriais

# Projetos do Code para o GitLab

Um passo a passo para:

  • Importar o repositório no GitLab;
  • Configurações no PM;
  • Configurações no DevOps.

Obs.: Esse guia foi feito com o GitLab (opens new window) em inglês.

# Considerações iniciais


  • Certifique-se de que nenhuma tarefa de seu projeto já tenha sido iniciada. Caso alguma tarefa possua arquivos "commitados", os passos do PM não poderão ser feitos.
  • O melhor momento para fazer a mudança é quando não há sprints e/ou projetos de erro pendentes, apenas um novo projeto ainda em planejamento.
  • Para os passos do GitLab, será necessário acesso de Administrador. Caso você não tenha, verifique com sua equipe pois alguém deve ter 😃

# GitLab

# Exportar projeto para o GitLab (opens new window)

  • Na Admin Area, vá no menu Users, localize e selecione o usuário Administrator.

admin

  • Click no botão Impersonate (no canto superior direito). Agora, tudo será feito por esse usuário e ele será o Owner do projeto (Não vamos ser donos dos projetos da Teknisa, ok?).

impersonate

  • Vá em Grupos -> Seus Grupos e localize o grupo referente ao seu projeto.
  • Click no botão Novo projeto.

novo_projeto

  • Nas abas, selecione Import project.

import_project

  • Selecione opção Repo by URL. Como os repositórios da Teknisa possuem acesso apenas interno (usuários logados), é necessário informar os dados de acesso. Caso contrário, a importação não irá funcionar.

repo_by_url

  • URL do repositório Git: Endereço http de acesso ao repositório. Ex.: http://192.168.122.56/zeedhi-components/zeedhi-interval-component.git
  • Username: Usuário de acesso ao code Ex.: phillipe.silva@teknisa.com
  • Password: Senha de acesso ao code. Ex.: aí não tem exemplo 😃

http_link

  • Confira as informações de Nome do projeto, URL do projeto, Slug do projeto, marque a opção Visibility Level como Interno e inicie a importação (pode demorar alguns instantes, mas se passar de 5 min, provavelmente algum dado está errado).

interno

# Desativar AutoDevOps

  • Como a pipeline ainda não foi completamente definida, é melhor que o AutoDevOps fique desabilitado.
  • No projeto, vá em Settings -> CI/CD.
  • Na parte referente ao AutoDevOps, desmarque a opção Default to Auto DevOps pipeline e salve.

auto_devops

# Proteger a branches stable e master

  • Esse processo garante que apenas o PM e o DevOps fiquem responsáveis por subir alterações nas branches principais.
  • Vá em Settings -> Repository.
  • Em Protected Branches, selecione:
    • Branch: stable;
    • Allowed to merge: Maintainers
    • Allowed to push: Maintainers

protected_branches

  • Logo abaixo, na branch master, altere a opção Allowed to push para Maintainers.

master

# Limpar repositório (Opcional)

  • Podem (e devem) existir "lixos" que poderão ser descartados, como branches auxiliares criadas a séculos que não serão mais usadas.
  • Vá em Repository -> Branches.
  • Utilize o botão Delete merged branches que já fará grande parte do trabalho por você.

Nota

Para utilizar essa opção, lembre-se de proteger a branch stable antes, pois ela poderá ser apagada junto!

  • Após algum tempo, verifique se ainda existem branches que não foram "mergeadas" no master e ainda podem ser descartadas.
# Adicionar usuários da equipe no grupo

  • Retorne ao grupo e vá em Members
  • Adicione os usuários da sua equipe como Developers, sem data de expiração (a não ser que você queira trollar alguém...).
  • Caso algum usuário não aparecer para ser relacionado, solicite que o mesmo logue no GitLab via protocolo LDAP para que seja criado automaticamente.
  • Esse passo não precisa ser feito sempre. Uma vez que um usuário tem acesso ao grupo, ele terá o mesmo acesso à todos os seus projetos.

Pronto! Seu repositório está importado e disponível para utilização. Já pode sair do usuário root, no botão Stop impersonation (lá no canto superior direito, do lado da sua foto de perfil) e realizar o próximo passo.

# Adicionar SSH do code no GitLab

  • Tenha certeza de não estar ainda com o usuário Administrator, pois quem precisa da SSH é você!
  • No Code (opens new window), vá em Profile Settings -> SSH Keys.
  • Pegue todas as SSH's que precisar e adicione no seu perfil do GitLab em Settings (menu que aparece ao clickar na sua foto de perfil) -> SSH Keys.
  • Caso não queira utilizar a mesma chave ou não possua, gere uma nova e adicione ao seu perfil.
  • Repasse esse passo sobre SSH para todos os membros da sua equipe.

# PM

# Adicionar novo repositório.

  • Selecione o projeto mais acima em sua árvore de projetos (geralmente é o do tipo Produto (manutenção)). Dessa forma, tudo será replicado para os projetos filhos (desde que você confirme).

Atenção

O projeto que é associado no DevOps é o do tipo Produto (manutenção). Certifique-se de que ele seja alterado.

  • Edite o repositório antigo, que aponta para o code, informando a URL do GitLab.
  • Como a URL mudou, será criado um novo repositório. Apague o antigo, que aponta para o code.
  • Adicionar local de conexão do novo repositório.
    • Antes de adicionar um local de conexão para o seu repositório recém associado ao projeto, caso você queira utilizar o mesmo diretório do anterior, será necessário renomear/remover/fazer backup (ou afins) da pasta, pois ela aponta para o repositório do code. É necessário fazer isso para que o PM clone o repositório do GitLab e passe a utilizá-lo.
      • As dependências, módulos ou tudo que foi instalado no anterior poderão ser mantidos, basta apenas movê-los para a nova pasta que será criada após o Play. Caso queira instalar tudo novamente, fique a vontade 😃
    • Com o diretório inexistente (ou com o repositório correto do GitLab), adicione seu local de conexão. Deixe preenchido apenas um tipo de diretório, ou Windows ou Outros sistemas operacionais, para evitar quaisquer tipo de inconsistência.
  • Agora, inicie, pause, conclua suas tarefas e seja feliz.
  • Repasse esse passo sobre os locais de conexão para todos os membros da sua equipe.

# DevOps

  • Em Product -> Repository, informe o Path e o Sequence do repositório que foi adicionado ao seu projeto. Caso o repositório era o principal do projeto, marque a opção Master.

# Translate

  • Lembrem-se de alterar (ou criar um novo) repositório no http://translate.teknisa.com. Toda a rotina era feita a partir do repositório do code, que será inutilizado. Além das configurações do próprio repositório, deve-se alterar também o relacionamento do repositório com o produto. Por último, criem ou solicitem a criação do WebHook no repositório recém criado.

← Atualização PHP 7.2 para PHP 7.4 →