Download as
Browse Code »

Commit 29071d23c9f4e33fe842a27fce2b83f13e68b449

Authored by Carlos Vieira
1 parent 1439880e
Exists in master

Renomeia para Markdown

Showing 2 changed files with 89 additions and 89 deletions   Show diff stats
README.md 0 → 100644
  Diff comments   View file @29071d2
... ... @@ -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
View file @1439880
... ... @@ -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.