From c54655552618686edcf61c621025f875ddf5e112 Mon Sep 17 00:00:00 2001 From: Carlos Vieira Date: Mon, 25 Jun 2018 11:09:12 -0300 Subject: [PATCH] Commit inicial --- README.rst | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+), 0 deletions(-) create mode 100644 README.rst diff --git a/README.rst b/README.rst new file mode 100644 index 0000000..a464b6f --- /dev/null +++ b/README.rst @@ -0,0 +1,82 @@ +Sugestões +********* + +Repositório com sugestões para o MP sobre alguns aspectos da TI. + +Caso alguém tenha sugestão pode abrir uma isssue ou um PR. + +CI/CD +===== +Para fazer deploy em desenvolvimento/homologação/produção é necessário intervenção manual de alguma pessoa. + +**Sugestão** Realizar deploy em ambiente de desenvolvimento a cada commit e no de homologação quando houver **TAGs** e para produção quando houver uma aprovação dos membros responsáveis. + +https://jenkins.io/blog/2018/05/16/pipelines-with-git-tags/ +https://stackoverflow.com/questions/7805603/is-it-possible-for-jenkins-to-automatically-detect-and-build-newly-created-tags +https://jenkins.io/doc/pipeline/steps/pipeline-input-step/ + + +Realizar testes automatizados +============================= +Durante o CI/CD realizar os testes automáticos que existirem. No Portal de Serviços os testes foram explicitamentes removidos durante o deploy e só eram realizados no final da Sprint. + +**Sugestão** Só aceitar deploy para homologação com o nível de cobertura definido no contrato. Caso contrário é rejeitado automaticamente. É preciso garantir o mínimo de cobertura no código. + +https://stackoverflow.com/questions/35540823/minimum-code-coverage-threshold-in-jacoco-gradle#43018683 + + +Para comentario dos commits: +============================ +Aguns dos commits tem só a referência do JIRA da empresa terceirizada. Isso deixa o comentário muito difícil de compreender pricipalmente pela falta de acesso ao JIRA e no futuro para outros desenvolvedores. + +**Sugestão** Poderia definir e seguir algumas práticas como: https://sethrobertson.github.io/GitBestPractices/ + + +Dar visibulidade da cobertura dos testes +======================================== +Atualmente usamos o Sonar para dar visibilidade dos testes e seus resultados. + +**Sugestão** Colocar na documentação do projeto (README) o badge para o projeto no Sonar com as checagens dos parâmetros do contrato. + + +Backlog do projeto +================== +Atualmente usamos vários softwares para a gestão do backlog. + +**Sugestão** Usar o próprio board issue do gitlab. Assim o backlog fica visível e disponível para discussão com todos os envolvidos. E possivelmente até com o cidadão. + +https://about.gitlab.com/features/issueboard/ + + +Usar pipelines +============== +Atualmente os projetos utilizam o Jenkins como ferramenta de CI/CD. + +**Sugestão** Usar o próprio pipeline do Gitlab para CI/CD. Assim é possível fazer o pipeline as code e é facilmente visto o que deu errado em um build. + +https://docs.gitlab.com/ee/ci/pipelines.html + + +Usar Chats +========== +Atualmente é difícil a conversa com os desenvolvedores. + +**Sugestão** Usar alguma ferramenta de Chat inclusive com integrações para um **chatops** + + +https://docs.gitlab.com/ee/ci/chatops/ +https://github.com/RocketChat/Chat.Code.Ship + + +Ter mais janelas de RDM (ou não precisar ter) +============================================= +Atualmente a RDM só pode ser executado em terça e quinta. + +**Sugestão** Poder realizar CI/CD de maneira automatizada sem a necessidade de RDM ou ter mais janelas. + + +Acesso aos Logs de produção +=========================== +Atualmente o acesso aos logs tem que ser liberados. + +**Sugestão** Disponibilizar automaticamente em alguma ferramenta como Kibana ou similar. -- libgit2 0.21.2