02

Prévia do material em texto

WBA1128_v1.0
Entrega e implantação contínua 
(DevOps)
Desenvolvimento de espaços 
de integração
Desenvolvimento de software distribuído, 
implantação de espaços de desenvolvimento, 
testes, integração, produção 
Bloco 1
Marco Ikuro Hisatomi
Fato: teste automatizado
• Utilização do Robot Framework (RF). Disponível em: 
https://robotframework.org/. Acesso em: 1 jun. 2022. 
Ferramenta para automatização de testes funcionais.
• Resultou em cerca de 70% do tempo com o teste de 
integração automatizado.
Quadro 1 – Simulação de testes manuais e automatizados
Fonte: adaptado de Fonseca (2021, p. 25).
Preparação e
automatização 
Primeira 
execução
Ciclo de execução
Manual 8h00m 8h10m 
0h10m
(2% manual)
Automatizado
08h00m + 02h00m
(20% para automatizar)
10:03h
0h03m
(0,5% automatizado)
Diferença Manual 20% menor Automatizado 70% menor
Modelo tradicional
Implementações
Teste
• São aprovadas várias regras de negócio e requisitos 
funcionais, após as implementações, os testes são 
realizados para as funcionalidades antes da entrega da 
Release.
Fonte: elaborada pelo autor.
Figura 1 – modelo tradicional para teste de release
Release
Continuous Integratione ContinuousDeployment
Implementações Release 1
Teste 1
Fonte: elaborada pelo autor.
Figura 2 – Teste de release e ambiente CD/CD
• O primeiro ciclo do CI/CD, aplicado no DevOps, é a 
aprovação de um requisito para ser entregue com uma 
funcionalidade, sendo que a Release 1 que é testada.
DevOps
Continuous Integratione ContinuousDeployment
Implementações
Teste 2
• O segundo ciclo do CI/CD, aplicado no DevOps, é a aprovação do 
segundo requisito para ser entregue com mais uma 
funcionalidade (complementando a release anterior), sendo que 
a Release 2 que é testada por completa.
Fonte: elaborada pelo autor.
Figura 3 – Teste de release e ambiente CD/CD (segundo ciclo)
Release 2
DevOps
Continuous Integratione ContinuousDeployment
Implementações
Teste N
• O N-ésimo ciclo do CI/CD, aplicado no DevOps, é a aprovação do 
N-ésimo requisito para ser entregue com mais uma 
funcionalidade (complementando a release anterior), sendo que 
a Release N que é testada por completa.
Fonte: elaborada pelo autor.
Figura 4 – Teste de release e ambiente CD/CD (no ciclo)
Release N
DevOps
Continuous Integratione ContinuousDeployment
Implementações
Teste
Fonte: elaborada pelo autor.
Figura 5 – Teste de release e ambiente CD/CD (final de projeto)
Release
DevOps
• Encontrar a velocidade de implementação das funcionalidades 
alinhada às adaptações, inovações e reduções.
• Manter e melhorar a qualidade na operação e no 
desenvolvimento, corrigindo os bugs das Releases anteriores.
• Manter a ótima comunicação e a cultura DevOps.
TDD BDD
Premissa. 
Teste unitário para alcançar 
100% de cobertura de código.
Horizontalizar a documentação do 
projeto e descrever cenários para 
guiar o desenvolvimento da 
aplicação.
Foco dos casos de 
testes. Descrever a funcionalidade.
Testar o comportamento do sistema 
na perspectiva do usuário.
Abordagem das 
possibilidades de 
testes.
Prever teste para causar erro e 
outro caso para validar e ter 
sucesso.
Considerar a quebra das histórias do 
usuário em fragmentos.
Métodos de 
testes.
Teste unitário e integração. Teste de aceitação.
Test Driven Development. Behavior-Driven Development.
Escolhendo teste dirigido
Quadro 2 – Testes dirigidos TDD e BDD
Fonte: elaborado pelo autor.
Desenvolvimento de espaços 
de integração
Desenvolvimento de software distribuído, 
implantação de espaços de desenvolvimento, 
testes, integração, produção 
Bloco 2
Marco Ikuro Hisatomi
Componentização na CI/CD
Quais características são importantes da componentização?
• Microsserviços:
• Uma arquitetura que flexibiliza o desenvolvimento em 
paralelo.
• O grupo especialista se responsabiliza pelo 
microsserviço, desde a ideação até a produção.
• Interface e uso fracamente acoplada.
• Interação livre entre os microsserviços.
Interface do Usuário
Microsserviço 1
Microsserviço 3
Microsserviço 2
Banco
de Dados 2
Banco
de Dados 1
Figura 6 - Evoluindo para microsserviços
Fonte: adaptada de Freeman (2021 p. 268).
DevOps com microsserviços
• Grupo especialista se responsabiliza pelo microsserviço, 
desde a ideação até a produção.
Interface do Usuário
Microsserviço 1
Microsserviço 3
Microsserviço 2
Banco
de Dados 2
Banco
de Dados 1
Interface 2 do Usuário
Microsserviço 5
Banco
de Dados 3
Microsserviço 6
Figura 7 - Evoluindo para microsserviços (reutilizar)
DevOps com microsserviços
• Baixo acoplamento permite a reutilização. 
Fonte: adaptada de Freeman (2021 p. 268).
Interface do Usuário
Microsserviço 1
Microsserviço 3
Microsserviço 2
Banco
de Dados 2
Banco
de Dados 1
Interface 2 do Usuário
Microsserviço 5
Banco
de Dados 3
Microsserviço 6
Figura 8 - Evoluindo para microsserviços (reutilização 2)
DevOps com microsserviços
• Várias aplicações faz uso do microsserviço, foram 
implementados com alta coesão.
Fonte: adaptada de Freeman (2021 p. 268).
Microsserviços
Black Box: design em caixa preta (individualmente).
Descentralizado: arquitetura baseada em esquema para 
qualquer bases de dados.
Independentes: permite atualização ou substituição de forma 
independente, sem afetar o funcionamento dos outros 
componentes.
Poliglota: independe dos sistemas operacionais, linguagens de 
programação, armazenamento de dados e ferramentas.
Refactoringna componentização
Priorizar (pilar: colaboração):
• Legibilidade das funções.
• Maior compreensão de todos.
• Facilidade de manutenção.
Evitar (pilares: escala e ferramenta):
• Nomeação incorreta de variáveis (padrão simples).
• Falta de comentários (suficiência).
• Duplicação de código (sem tolerância).
• Inserção de métodos em classes inadequadas (coesão).
Desenvolvimento de espaços de 
integração
Perfil colaborativo
Kanban
Bloco 3
Marco Ikuro Hisatomi
Perfil colaborativo
Quadro 3 – Exemplo de perfil organizacional da Lei de Conway
Fonte: adaptado de Muniz (2020, p. 37).
Tipo de estrutura Características Resultados
Organizações 
hierarquizadas 
(comando e 
controle).
Pouca 
colaboração e 
comunicação 
ineficaz.
Sistemas com mais controles que valor, 
processos engessados e lentidão de 
resposta ao mercado e aos clientes, 
sistemas desatualizados.
Organizações 
flexíveis e equipes 
com grande 
autonomia.
Forte 
colaboração e 
objetivos 
compartilhados.
Sistemas modulares, fluxo de valor 
efetivo e adaptabilidade para atender a 
mercado e clientes.
Kanban = cartão em japonês
Figura 9 - Kanban = cartão em japonês
Fonte: https://www.ciamakers.com/kanban.pdf. Acesso em: 1 jun. 2022.
Kanban = cartão em japonês
• Já foi resolvida a falta de acesso/ configuração do 
Repositório de Código-fonte pela VPN Paraná-café? A
• Qual é o esforço necessário para implementar o método de 
carga de containers de 40 pés ? J
• Qual funcionalidade está em homologação?
• Qual funcionalidade aguarda correção? S
Kanban = cartão em japonês
Figura 10 - Kanban = cartão em japonês
Fonte: adaptada de 
https://www.ciamakers.com/kanban.pdf. Acesso 
em: 1 jun. 2022.
Impedimentos A
Teoria em Prática
Bloco 4
Marco Ikuro Hisatomi
Desafio: apresentar uma proposta de CI/CD
Apresentar um processo CI/CD, que reflete a realidade do 
negócio, proporcionará segurança na operação e, 
consequentemente, satisfação ao time de Integração, baseado 
em DevOps:
1. Se o cliente possui integração com diversas aplicações, 
componentes e serviços (ou microsserviços), o deployment
pode se tornar uma fase crítica.
2. Após a conclusão da fase de Integração, quando entende-
se que todos os componentes necessários da aplicação 
estejam devidamente em Commit, o próximo passo é tão 
importante quanto a todos que foram realizados: 
integração contínua do código de infraestrutura. 
Norte para a resolução
Pipeline de implantação. 
Representa as etapas necessárias para que tenhamos software em 
um estado implementávele permite o feedback rápido em caso de 
falhas, segundo Muniz e Moutinho (2020). 
Em pesquisa realizada por Sato (1998, p. 234): 
A ferramenta Go, escrita pela ThoughtWorks, teve seu 
código recentemente aberto e foi escrita com a 
pipeline de entrega em primeiro plano. Com um 
modelo de execução de jobs distribuído e uma forma 
de modelar diferentes ambientes, o Go é uma opção 
atraente para gerenciar pipelines complexas. (SATO, 
1998, p. 234)
Go está disponível em: http://www.go.cd/. Acesso em: 1 jun. 2022.
Ambiente de Teste
Build – Testes Unitários –
Teste de Integração
Repositório
Código fonte – Commit –
Pull Request
Deploy em 
Staging
Falha
Sucesso
Deploy em 
Produção
Se 
Sucesso
Se 
Sucesso
Sim
Sim
Fonte: adaptada de Trindade (2021 p. 48).
Duas fases na Pipeline para garantir o Deploy correto em 
produção.
Norte para a resolução
Figura 11 - Fluxograma da pipeline de CI/CD
Fonte: adaptado de Zaal (2020, p. 57).
Com duas fases na Pipeline de Deploy, a colaboração do time 
de desenvolvimento é fundamental para garantir a qualidade 
na entrega.
Norte para a resolução
Figura 12 – Necessidade de merge
c#3
c#A
c#B
c#C
Espaço de Desenvolvimento 
Distribuído
Engenheiro 
AtsushiEngenheira 
Hisako
Dicas do(a) Professor(a)
Bloco 5
Marco Ikuro Hisatomi
Prezado aluno, as indicações a seguir podem estar disponíveis 
em algum dos parceiros da nossa Biblioteca Virtual (faça o login
através do seu AVA). Algumas indicações também podem estar 
disponíveis em sites acadêmicos como o Scielo, repositórios de 
instituições públicas, órgãos públicos, anais de eventos 
científicos ou periódicos científicos, acessíveis pela internet.
Isso não significa que o protagonismo da sua jornada de 
autodesenvolvimento deva mudar de foco. Reconhecemos que 
você é a autoridade máxima da sua própria vida e deve, 
portanto, assumir uma postura autônoma nos estudos e na 
construção da sua carreira profissional. 
Por isso, te convidamos a explorar todas as possibilidades da 
nossa Biblioteca Virtual e além! Sucesso!
Leitura Fundamental
Indicação de leitura 1
Uma cultura muito famosa, porém, na prática, muitos projetos 
ficam a desejar. Na CI/CD, isso é importante!
Fazer pequenas alterações no código com o objetivo de 
melhorar sua manutenibilidade, aumentando, dessa forma, 
sua simplicidade, flexibilidade, clareza e desempenho.
Referência:
MARTINS, J. C.; LEAL, M. F. Melhorando a manutenibilidade das aplicações. 2022.
Indicação de leitura 2
Leia o tópico sobre DevOps fora da TI, no capítulo 28.
Faça uma reflexão sobre as influências positivas ou negativas, 
que podem fazer muita diferença para o sucesso do DevOps 
em uma organização.
Referência:
MUNIZ, A. Jornada DevOps. Brasport, 1.10, 2020. 
Dica do(a) Professor(a)
Quer praticar o controle de versão num ambiente de 
desenvolvimento de espaços de integração?
Na prática, poderá escolher ferramentas seguras e produtivas 
para desenvolver o CI/CD, como exemplo, fica a sugestão 
desse vídeo, demonstrando os passos fundamentais no 
controle de arquivos de códigos-fonte, usando o Git. 
Lembrando que o uso da ferramenta não dispensa os 
princípios do DevOps e das atividades de gestão de projetos.
Assista apresentação sobre espaços de Desenvolvimento 
Contínuo. Acesse o YouTube e o canal DevSuperior, em 
seguida procure por: Tutorial Git e Github 2022 - Introdução 
prática para iniciantes (34m05s).
Referências
FREEMAN, E. DevOps para leigos. São Paulo: Alta Books, 2021.
MARTINS, J. C.; LEAL, M. F. Melhorando a manutenibilidade das aplicações. 
Disponível em: http://www.batebyte.pr.gov.br/Pagina/ Melhorando-
manutenibilidade-das-aplicações. Acesso em: 1 jun. 2022.
MUNIZ, A. Jornada DevOps. Brasport, 1.10, 2020. Disponível em: 
https://plataforma.bvirtual.com.br/Leitor/Publicacao/180926/epub/0?code=3BNO
f8rvvlv9LDc9rFCfN42W20PnIuJ5YRJwxl41qBFYWYu/EH5ippB7D0x7GKYVmLJrEN/e
UkdvWeVigSSJdg==>. Acesso em: 1 jun. 2022.
SAFF, D.; ERNST, M. D. An experimental evaluation of continuous testing during 
development. ACM SIGSOFT Software Engineering Notes, 29.4, p. 76–85, 2004.
SATO, D. DevOps na prática: entrega de software confiável e automatizada. São 
Paulo: Caso do Código, 1998.
STRESNJAK, S.; HOCENSKI, Z. Usage of robot framework in automation of functional
test regression. Proc. 6th Int. Conf. Softw. Eng. Adv.(ICSEA), p. 30–34, 2011.
Bons estudos!