Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- pres:gerti:processos_de_ti:pds [12/05/2026 14:20] – ivinicius
+++ pres:gerti:processos_de_ti:pds [19/05/2026 10:40] (atual) – [2.4 Gestão de Riscos] ivinicius
@@ Linha 14: / Linha 14: @@
 ==== 2.4 Gestão de Riscos ====
+A gestão de riscos trata dos da identificação, controle e eliminação/mitigação de riscos do projeto, os quais são identificados desde o início do projeto até o momento da descontinuação deste.
 ==== 2.5 Marcos, Cronograma e Prazos ====
@@ Linha 53: / Linha 56: @@
 No repositório Git de cada projeto, apenas as branchs //**main/master**//  e //**develop**//  existirão durante todo o ciclo de vida do projeto. Mas além dessas branchs poderão existir de forma temporária de com ciclo de vida bem definidas como as:
-   * **Features**: branchs de evoluções (em projetos), cujo prefixo de nomenclatura será //**feat/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade}**//  (exemplo
+   * **Features**: branchs de evoluções (em projetos), cujo prefixo de nomenclatura será //**feat/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade}**// (exemplo //**feat/#40441-Servico-de-consulta-de-analistas-responsaveis**//);
-//**feat/#40441-Servico-de-consulta-de-analistas-responsaveis**//  );
-  * **Hotfix**: branches de correções emergenciais de erros de produto do projeto que estão implantados em produção, cujo prefixo de nomenclatura será //**hotfix/{#ID da história/tarefa do redmine}-{nome sem espaço do erro}**//  (exemplo
+  * **Hotfix**: branches de correções emergenciais de erros de produto do projeto que estão implantados em produção, cujo prefixo de nomenclatura será //**hotfix/{#ID da história/tarefa do redmine}-{nome sem espaço do erro}**// (exemplo //**hotfix/#40061-Correção-BUG-sincronização-Addins-trâmite**//);
-//**hotfix/#40061-Correção-BUG-sincronização-Addins-trâmite**//  );
-  * **Deveolp concorrente**: caso de projetos com mais de um projeto de evolução sendo executado ao mesmo tempo, para que a branche de desenvolvimento fique limpa (//**devolop**//  ), e caso cada não dependa um do outro, a equipe de cada projeto deverá criar uma branch de desenvolvimento a partir da //**devolop**//  , seguindo a seguinte prefixo de nomenclatura será //**devolop/{#ID da história/tarefa do redmine}-{nome sem espaço do erro}**//  (exemplo
+  * **Deveolp concorrente**: caso de projetos com mais de um projeto de evolução sendo executado ao mesmo tempo, para que a branche de desenvolvimento fique limpa (//**devolop**//  ), e caso cada não dependa um do outro, a equipe de cada projeto deverá criar uma branch de desenvolvimento a partir da //**devolop**//  , seguindo a seguinte prefixo de nomenclatura será //**devolop/{#ID da história/tarefa do redmine}-{nome sem espaço do erro}**// (exemplo //**devolop/#40441-Servico-de-consulta-de-analistas-responsaveis**//). Dessa forma, a autalização para testes funcionais de cada projeto deverá ser realizado via branch release, como descrito a seguir;
-//**devolop/#40441-Servico-de-consulta-de-analistas-responsaveis**//  ). Dessa forma, a autalização para testes funcionais de cada projeto deverá ser realizado via branch release, como descrito a seguir;
-  * **Release**: branchs de candidata a release de alterações que irá entrar em produção, seja de correções vindas de uma hotfix, ou de evoluções de projetos que estavam sendo desenvolvidos na branch //**devolop**//  . Nessa branch, em particular, sempre que as alterações dela forem sendo concluídas, após o //**Merge Request**//  dela para para a //**main/master**//  for concluído com sucesso, deve ser atualizado de imediato na branch //**develop**//  com o resultado do merge da //**main/master**//  . Dessa forma, projetos que antes estavam trabalhando na develop só vão para produção via branch release. A nomenclatura das branch de release terão o prefixo //**release**//  , e seguirão o seguinte padrão //**release/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade/erro}**//  (exemplo
+  * **Release**: branchs de candidata a release de alterações que irá entrar em produção, seja de correções vindas de uma hotfix, ou de evoluções de projetos que estavam sendo desenvolvidos na branch //**devolop**//  . Nessa branch, em particular, sempre que as alterações dela forem sendo concluídas, após o //**Merge Request**//  dela para para a //**main/master**//  for concluído com sucesso, deve ser atualizado de imediato na branch //**develop**// com o resultado do merge da //**main/master**//. Dessa forma, projetos que antes estavam trabalhando na develop só vão para produção via branch release. A nomenclatura das branch de release terão o prefixo //**release**//, e seguirão o seguinte padrão //**release/{#ID da história/tarefa do redmine}-{nome sem espaço da funcionalidade/erro}**// (exemplo //**release/#40441-Servico-de-consulta-de-analistas-responsaveis**//  ou //**release/#40061-Correção-BUG-sincronização-Addins-trâmite**//).
-//**release/#40441-Servico-de-consulta-de-analistas-responsaveis**//  ou //**release/#40061-Correção-BUG-sincronização-Addins-trâmite**//  ).
 === 3.4.3.1 Criando branche Hotfix ===
@@ Linha 112: / Linha 111: @@
 === 3.4.3.3 Criando branche Release ===
 Antes de criar uma branch de candidata a release do sistema, tanto para branch de **Hotfix** quando para branch de **Feature**, a branch de origem da release deve estar sempre atualizada com as ultimas alterações da branch de origem daquela, se **Hotfix** com as ultimas alterações da **main/master** se ouver, e se feature das ultimas atualizações da **develop** se exitir. Esse cuidado é de extrema importância para garantir que o código que será disponibilizado para o ambiente de homologação e testes finais esteja sempre atualizados com as correções e evoluções que antecederam a essa nova candidata a release. **Esse procedimento de garantir que esteja atualizado é obrigatório**.
+Utilizando como exemplo que a hotfix da tarefa #40132-Correção BUG editar primeira vez tenha finalizado, vamos criar uma candidata a release a partir da brach hotfix/#40132-Correção-BUG-editar-primeira-vez, através do seguinte comando:
 <code>
-git switch -c hotfix/#40132-Correção-BUG-editar-primeira-vez
+git switch -c release/#40132-Correção-BUG-editar-primeira-vez
 </code>
-Após executar o comando na listagem dos branchs para verificar qual branch está sendo apontado, veremos que o git está apontando para a nova branch, como apresentado na imagem abaixo:
+Após a criação da candidata a release, caso tenha correções e ajustes identificados durante a homologação e testes finais, os quais vão ser comitados nessa branch, não há necessidade de criar nova branch para implementar correções. Essas operações deverão ser realizados nessa branch candidata, e quando concluir a partir dela será realizado o Merge Request para a main/master para ser implantada no ambiente de produção.
-{{ :pres:gerti:processos_de_ti:git-hotfix.png?1200 |}}
+Após executar o comando na listagem dos branchs para verificar qual branch está sendo apontado, veremos que o git está apontando para a nova branch de candidata a release, como apresentado na imagem abaixo, deve ser removida a brach de hotfix de origem. **Atenção - candidata a release de origem da branch develop nunca poderão ser removidas, apenas as branchs da develop de implementação concorrentes com prefixo como nesse exemplo //**devolop/#40441-Servico-de-consulta-de-analistas-responsaveis**// podem ser removidas após Merge Request com a branch develop**:
+{{ :pres:gerti:processos_de_ti:git-release-hotfix.png?1200 |}}
 === 3.4.3.4 Merge Request ===
+Em todos os projetos [[https://gitsource.tce.go.gov.br/|Git]] a branch padrão main/master sempre estarão protegitas para commits e merge, sendo possível atualizar nela apenas via Merge Request. Seguindo o modelo [[https://about.gitlab.com/blog/what-is-gitflow/|GitFlow]], as alterações nessa branch serão via correções advindas de branch de release que por sua vez vem de uma branch hotfix, ou via projetos de evolução/melhorias de branch release que veio da develop.
+Toda atualização na branch main/master irá gerar uma nova versão estável do sistema, uma nova Tag, que seguira o padrão do [[pres:gerti:devops:informacoes:versionamento_semantico|Semantic Version]], que irá incrementar a versão nas posições Major.Minor.Path conforme os commits que compõem a versão.
+Para criar um Merg Request podemos fazê-lo via [[https://gitsource.tce.go.gov.br/|GitLab]], através do seguinte menu demonstrado na imagem abaixo:
+{{ :pres:gerti:processos_de_ti:menu-merge-request.png?1200 |}}
+Na tela seguinte escolhemos a branch de origem que queremos levar as alterações para a branch de destino no campo 1 (Source branch), e no campo 2 escolhemos a branch de destino (Target branch). Abaixo de cada campo é apresentada a ultima alteração realizada nas branches.
+Selecionado corretamente a branch de origem e a branch de destino, basta clicar no botão em 3 (Compare branches and continue) para  ir para a próxima etapa de documentação do Merge Request.
+{{ :pres:gerti:processos_de_ti:merge-request-source.png?1200 |}}
+Nessa próxima tela deve se documentar o Merge Request, informando o título (campo 1), a descrição das alterações da branch de origem (campo 2), selecione em Assignee o responável pela aprovação (campo 3), no campo Reviewer selecione o responável pela revisão das alterações realizadas na branch (campo 4). Marque a opção para deletar a branch de origem após a aceitação do Merge Request (campo 5), quando a origem for de uma branch de release, hotfix e feat, ou em caso de branch de develop concorrente. Após verificado o preenchimento correto clique no botão para criar o merg request (campo 6).
+{{ :pres:gerti:processos_de_ti:form-merge-request.png?1200 |}}
+Após a criação do Merge Request, uma tarefa será aberta no GitLab para o responsável pelo merge selecionado anteriormente.
+Outra forma de criar o Merge Request é via comando git no prompt do Windows. Para criar via prompt, deve especificar a criação no momento de subir às alterações no comando //**"push"**//, seguindo os seguintes comandos abaixo:
+<code>
+git push -o merge_request.create -o merge_request.title="<titulo conforme padrão de Nomenclatura de Commits>" -o merge_request.description="<descrição detalhada das alterações da branch criada, conforme o tipo>" -o merge_request.assignee="<nome usuário do responsável (ex.: ivinicius)>" -o merge_request.reviewer="<nome do usuário responsável (ex.: ivinicius)>" -o merge_request.remove_source_branch origin <nome da branch de origem>
+</code>
+**Atenção:** criando o Merge Request via comando git, a branch de destino será a branch de origem da branch atual, conforme cada tipo, como se pode observar abaixo nas imagens do passo a passo sendo realizada via prompt:
+{{ :pres:gerti:processos_de_ti:git-push-create-merge-request.png?1200 |}}
+Após executado o comando, acessando o GitLab, na opção do menu Code -> Merge requests, identificamos que foi criada uma tarefa de Merge Request conforme o comando executado:
+{{ :pres:gerti:processos_de_ti:merge-request-creat-shell.png?1200 |}}
+Abrindo o Marge Requeste, verificaremos que o título, a descrição e a configuração de deletar o branch de origem foi selecionado conforme o comando executado, e que a branch de destino o merge será a branch de origem da branch de trabalho, conforme o tipo (hotfix, feat e release), conforme apresentado na imagem abaixo:
+{{ :pres:gerti:processos_de_ti:merge-request-creat-shell-details.png?1200 |}}
+Aprovado o Merge Request na sua tarefa, o procedimento de merge vai ser realizado e após a conclusão a branch de origem, no caso a hotfix será deletada, conforme apresentado abaixo:
+{{ :pres:gerti:processos_de_ti:merge-request-creat-shell-details-done-merge.png?1200 |}}
+{{ :pres:gerti:processos_de_ti:gitlab-graph-branches.png?1200 |}}
 ==== 3.4.4 Padrão de Commits (Conventional Commits) ====