Download as
Browse Code »

Commit de52ef7ba1d4f522958f55d0ca090ac721ab1f9f

Authored by Carlos Vieira
1 parent 29071d23
Exists in master

Altera formatação

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