Commit 29071d23c9f4e33fe842a27fce2b83f13e68b449
1 parent
1439880e
Exists in
master
Renomeia para Markdown
Showing
2 changed files
with
89 additions
and
89 deletions
Show diff stats
| @@ -0,0 +1,89 @@ | @@ -0,0 +1,89 @@ | ||
| 1 | +Sugestões | ||
| 2 | +********* | ||
| 3 | + | ||
| 4 | +Repositório com sugestões para o MP sobre alguns aspectos da TI. | ||
| 5 | + | ||
| 6 | +Caso alguém tenha sugestão pode abrir uma isssue ou um PR. | ||
| 7 | + | ||
| 8 | +CI/CD | ||
| 9 | +===== | ||
| 10 | +Para fazer deploy em desenvolvimento/homologação/produção é necessário intervenção manual de alguma pessoa. | ||
| 11 | + | ||
| 12 | +**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. | ||
| 13 | + | ||
| 14 | +https://jenkins.io/blog/2018/05/16/pipelines-with-git-tags/ | ||
| 15 | +https://stackoverflow.com/questions/7805603/is-it-possible-for-jenkins-to-automatically-detect-and-build-newly-created-tags | ||
| 16 | +https://jenkins.io/doc/pipeline/steps/pipeline-input-step/ | ||
| 17 | + | ||
| 18 | + | ||
| 19 | +Realizar testes automatizados | ||
| 20 | +============================= | ||
| 21 | +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. | ||
| 22 | + | ||
| 23 | +**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. | ||
| 24 | + | ||
| 25 | +https://stackoverflow.com/questions/35540823/minimum-code-coverage-threshold-in-jacoco-gradle#43018683 | ||
| 26 | + | ||
| 27 | + | ||
| 28 | +Para comentario dos commits: | ||
| 29 | +============================ | ||
| 30 | +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. | ||
| 31 | + | ||
| 32 | +**Sugestão** Poderia definir e seguir algumas práticas como: https://sethrobertson.github.io/GitBestPractices/ | ||
| 33 | + | ||
| 34 | + | ||
| 35 | +Dar visibulidade da cobertura dos testes | ||
| 36 | +======================================== | ||
| 37 | +Atualmente usamos o Sonar para dar visibilidade dos testes e seus resultados. | ||
| 38 | + | ||
| 39 | +**Sugestão** Colocar na documentação do projeto (README) o badge para o projeto no Sonar com as checagens dos parâmetros do contrato. | ||
| 40 | + | ||
| 41 | + | ||
| 42 | +Backlog do projeto | ||
| 43 | +================== | ||
| 44 | +Atualmente usamos vários softwares para a gestão do backlog. | ||
| 45 | + | ||
| 46 | +**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. | ||
| 47 | + | ||
| 48 | +https://about.gitlab.com/features/issueboard/ | ||
| 49 | + | ||
| 50 | + | ||
| 51 | +Usar pipelines | ||
| 52 | +============== | ||
| 53 | +Atualmente os projetos utilizam o Jenkins como ferramenta de CI/CD. | ||
| 54 | + | ||
| 55 | +**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. | ||
| 56 | + | ||
| 57 | +https://docs.gitlab.com/ee/ci/pipelines.html | ||
| 58 | + | ||
| 59 | + | ||
| 60 | +Usar Chats | ||
| 61 | +========== | ||
| 62 | +Atualmente é difícil a conversa com os desenvolvedores. | ||
| 63 | + | ||
| 64 | +**Sugestão** Usar alguma ferramenta de Chat inclusive com integrações para um **chatops** | ||
| 65 | + | ||
| 66 | + | ||
| 67 | +https://docs.gitlab.com/ee/ci/chatops/ | ||
| 68 | +https://github.com/RocketChat/Chat.Code.Ship | ||
| 69 | + | ||
| 70 | + | ||
| 71 | +Ter mais janelas de RDM (ou não precisar ter) | ||
| 72 | +============================================= | ||
| 73 | +Atualmente a RDM só pode ser executado em terça e quinta. | ||
| 74 | + | ||
| 75 | +**Sugestão** Poder realizar CI/CD de maneira automatizada sem a necessidade de RDM ou ter mais janelas. | ||
| 76 | + | ||
| 77 | + | ||
| 78 | +Acesso aos Logs de produção | ||
| 79 | +=========================== | ||
| 80 | +Atualmente o acesso aos logs tem que ser liberados. | ||
| 81 | + | ||
| 82 | +**Sugestão** Disponibilizar automaticamente em alguma ferramenta como Kibana ou similar. | ||
| 83 | + | ||
| 84 | + | ||
| 85 | +Sprints com features e bugs | ||
| 86 | +=========================== | ||
| 87 | +Atualmente as sprints concorrem com os bugs e features. Isso torna a geração de valor com novas features mais difícil e moroso. | ||
| 88 | + | ||
| 89 | +**Sugestão** As sprints serem somente para novas features e os bugs não ocupam slot de tempo na sprint. |
README.rst
| @@ -1,89 +0,0 @@ | @@ -1,89 +0,0 @@ | ||
| 1 | -Sugestões | ||
| 2 | -********* | ||
| 3 | - | ||
| 4 | -Repositório com sugestões para o MP sobre alguns aspectos da TI. | ||
| 5 | - | ||
| 6 | -Caso alguém tenha sugestão pode abrir uma isssue ou um PR. | ||
| 7 | - | ||
| 8 | -CI/CD | ||
| 9 | -===== | ||
| 10 | -Para fazer deploy em desenvolvimento/homologação/produção é necessário intervenção manual de alguma pessoa. | ||
| 11 | - | ||
| 12 | -**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. | ||
| 13 | - | ||
| 14 | -https://jenkins.io/blog/2018/05/16/pipelines-with-git-tags/ | ||
| 15 | -https://stackoverflow.com/questions/7805603/is-it-possible-for-jenkins-to-automatically-detect-and-build-newly-created-tags | ||
| 16 | -https://jenkins.io/doc/pipeline/steps/pipeline-input-step/ | ||
| 17 | - | ||
| 18 | - | ||
| 19 | -Realizar testes automatizados | ||
| 20 | -============================= | ||
| 21 | -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. | ||
| 22 | - | ||
| 23 | -**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. | ||
| 24 | - | ||
| 25 | -https://stackoverflow.com/questions/35540823/minimum-code-coverage-threshold-in-jacoco-gradle#43018683 | ||
| 26 | - | ||
| 27 | - | ||
| 28 | -Para comentario dos commits: | ||
| 29 | -============================ | ||
| 30 | -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. | ||
| 31 | - | ||
| 32 | -**Sugestão** Poderia definir e seguir algumas práticas como: https://sethrobertson.github.io/GitBestPractices/ | ||
| 33 | - | ||
| 34 | - | ||
| 35 | -Dar visibulidade da cobertura dos testes | ||
| 36 | -======================================== | ||
| 37 | -Atualmente usamos o Sonar para dar visibilidade dos testes e seus resultados. | ||
| 38 | - | ||
| 39 | -**Sugestão** Colocar na documentação do projeto (README) o badge para o projeto no Sonar com as checagens dos parâmetros do contrato. | ||
| 40 | - | ||
| 41 | - | ||
| 42 | -Backlog do projeto | ||
| 43 | -================== | ||
| 44 | -Atualmente usamos vários softwares para a gestão do backlog. | ||
| 45 | - | ||
| 46 | -**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. | ||
| 47 | - | ||
| 48 | -https://about.gitlab.com/features/issueboard/ | ||
| 49 | - | ||
| 50 | - | ||
| 51 | -Usar pipelines | ||
| 52 | -============== | ||
| 53 | -Atualmente os projetos utilizam o Jenkins como ferramenta de CI/CD. | ||
| 54 | - | ||
| 55 | -**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. | ||
| 56 | - | ||
| 57 | -https://docs.gitlab.com/ee/ci/pipelines.html | ||
| 58 | - | ||
| 59 | - | ||
| 60 | -Usar Chats | ||
| 61 | -========== | ||
| 62 | -Atualmente é difícil a conversa com os desenvolvedores. | ||
| 63 | - | ||
| 64 | -**Sugestão** Usar alguma ferramenta de Chat inclusive com integrações para um **chatops** | ||
| 65 | - | ||
| 66 | - | ||
| 67 | -https://docs.gitlab.com/ee/ci/chatops/ | ||
| 68 | -https://github.com/RocketChat/Chat.Code.Ship | ||
| 69 | - | ||
| 70 | - | ||
| 71 | -Ter mais janelas de RDM (ou não precisar ter) | ||
| 72 | -============================================= | ||
| 73 | -Atualmente a RDM só pode ser executado em terça e quinta. | ||
| 74 | - | ||
| 75 | -**Sugestão** Poder realizar CI/CD de maneira automatizada sem a necessidade de RDM ou ter mais janelas. | ||
| 76 | - | ||
| 77 | - | ||
| 78 | -Acesso aos Logs de produção | ||
| 79 | -=========================== | ||
| 80 | -Atualmente o acesso aos logs tem que ser liberados. | ||
| 81 | - | ||
| 82 | -**Sugestão** Disponibilizar automaticamente em alguma ferramenta como Kibana ou similar. | ||
| 83 | - | ||
| 84 | - | ||
| 85 | -Sprints com features e bugs | ||
| 86 | -=========================== | ||
| 87 | -Atualmente as sprints concorrem com os bugs e features. Isso torna a geração de valor com novas features mais difícil e moroso. | ||
| 88 | - | ||
| 89 | -**Sugestão** As sprints serem somente para novas features e os bugs não ocupam slot de tempo na sprint. |