CI CD difere de DevOps? Muito comum no dia a dia de profissionais de tecnologia da informação, o CI/CD é um conjunto de práticas de integração e entrega contínua para que as equipes de desenvolvimento de aplicativos entreguem alterações de código com mais frequência e confiabilidade.

Ela é uma ação recomendada para equipes de desenvolvedores e operações, sendo também indicada para uso na metodologia ágil. Ao automatizar a integração e a entrega, os integrantes dos grupos de desenvolvimento de software irão conseguir se concentrar em atender aos requisitos de negócios, garantindo a qualidade do código e a segurança do software.

A maioria dos aplicativos modernos exige o desenvolvimento de código usando uma variedade de plataformas e ferramentas, portanto, os times precisam de um mecanismo consistente para integrar e validar as alterações.

Já DevOps une práticas e funcionalidades construídas para encurtar o ciclo de vida de desenvolvimento de sistemas, e aumentar a capacidade de determinado negócio de fornecer aplicativos e serviços em um tempo menor.

Entenda mais sobre o que é CI/CD, para que serve, diferença entre um e outro, relação com DevOps, benefícios e mais. Boa leitura!

O que é CI/CD?

O CI/CD é um método para entregar softwares com frequência aos clientes, introduzindo a automação nos estágios de desenvolvimento de aplicativos. Os principais conceitos atribuídos são integração contínua, entrega contínua e implantação contínua.

Integração contínua (CI)

A integração contínua (CI) é uma prática onde os desenvolvedores realizam pequenas alterações e verificações em um código. Devido à escala de requisitos e ao quantitativo de fases envolvidas, esse fluxo é automatizado para garantir que os times possam desenvolver, testar e finalizar os aplicativos de maneira confiável.

Em síntese, a CI ajuda principalmente a simplificar as alterações de código, aumentando assim o tempo para que os desenvolvedores façam alterações e contribuam para melhorar o software.

Entrega contínua (CD)

A entrega contínua (CD) é a entrega automatizada de um código completo para ambientes como teste e desenvolvimento. Tecnicamente, ele fornece uma maneira automatizada e funciona para que o código seja entregue a esses ambientes.

Você sabia que a implantação contínua é a próxima etapa da entrega contínua? Isso mesmo! Cada alteração que passa nos testes automatizados é automaticamente colocada em produção, resultando em muitas implantações de produção.

A implantação contínua deve ser o objetivo da maioria das empresas que não são limitadas por requisitos regulamentares ou outros.

Para que serve o CI/CD?

Entenda que o CI/CD é uma solução para os problemas que a integração de um novo código pode causar para equipes de desenvolvimento e operações — também conhecido como “integration hell”, em português “inferno de integração”.

Ele especificamente apresenta automação contínua e monitoramento contínuo em todo o ciclo de vida dos aplicativos, desde as fases de integração e teste até a entrega e implantação.

Em conjunto, essas práticas conectadas são frequentemente chamadas de “pipeline CI/CD” e apoiadas por equipes de desenvolvimento e operações que trabalham juntas, de maneira ágil, com uma abordagem DevOps ou engenharia de confiabilidade do site (SRE, em inglês para Site Reliability Engineering).

Qual a diferença entre CI e CD?

Os termos CI e CD tem aplicabilidades distintas, mas que se completam.🧐

O “CI” sempre vai se referir à integração contínua que é um processo de automação para desenvolvedores. A CI bem-sucedida significa que novas alterações de código em um aplicativo são criadas, testadas e mescladas regularmente em um repositório compartilhado.

É uma solução para o problema de ter muitas ramificações de um aplicativo em desenvolvimento enquanto elas podem entrar em conflito entre si.

Já o “CD” tem como referência à entrega contínua e/ou implantação contínua, conceitos relacionados, podendo, às vezes, ser usados ​​de forma intercambiável. Ambos tratam da automatização de outros estágios do pipeline, mas por vezes são usados ​​separadamente para ilustrar o quanto de automação está acontecendo.

Resumindo, CI é um conjunto de práticas executadas enquanto os desenvolvedores escrevem código e CD é um conjunto de práticas executadas após a conclusão do código.

Como diferenciar CI/CD do DevOps, em geral?

Você precisa entender que o pipeline integra a estrutura DevOps/DevSecOps mais ampla, enquanto DevOps trata-se de um conjunto de práticas e funcionalidades desenvolvidas para aumentar a capacidade de um negócio de fornecer softwares e serviços de forma mais rápida do que processos tradicionais de desenvolvimento.

Em um espaço DevOps, as empresas bem-sucedidas “colocam segurança” em todas as etapas e fluxos do ciclo de vida do desenvolvimento, uma prática chamada DevSecOps.

Veja as diferenças entre CI/CD e DevOps:

Principais ferramentas para CI/CD

O Gitlab é uma aplicação muito atrativa composta de ferramentas e recursos diversos para ajudar os desenvolvedores em seu processo de DevOps.

Você pode ter sua própria instância local (on-premises) ou na nuvem pública, ou até mesmo usar a oferta SaaS hospedada pelo GitLab! Há gratuidade nos dois casos.

Outra coisa é que muitas equipes usam sinalizadores de recursos, um mecanismo de configuração para ativar ou desativar recursos e códigos em tempo de execução.

Os recursos ainda em desenvolvimento são agrupados com sinalizadores de recurso no código, implantados com a ramificação principal para produção e desativados até que estejam prontos para serem usados.

Em pesquisas recentes, as equipes DevOps que usam sinalizadores de recursos tiveram um aumento de nove vezes na frequência de desenvolvimento. Ferramentas de sinalização de recursos como CloudBees, Optimizely Rollouts e LaunchDarkly integram-se com ferramentas de CI/CD para oferecer suporte a configurações de nível de recurso.

Uma vez que a equipe de desenvolvimento tenha selecionado uma ferramenta de CI/CD, ela deve garantir que todas as variáveis ​​de ambiente sejam configuradas fora do aplicativo. 

As ferramentas de CI/CD permitem que as equipes de desenvolvimento definam essas variáveis, mascarem variáveis ​​como senhas e chaves de conta e as configurem no momento da implantação para o ambiente de destino.

Exemplos de utilização de CI/CD

Imagine um ambiente de trabalho em que vários desenvolvedores trabalhem simultaneamente fazendo a integração de códigos na ramificação principal de um repositório comum.

Em vez de criar recursos isoladamente e enviar cada um deles no final do ciclo, um profissional se esforça para contribuir com produtos de trabalho de software para o repositório várias vezes em um determinado dia. Muito mais fácil, né?

A grande ideia aqui é reduzir os custos de integração, fazendo com que os desenvolvedores programem mais cedo e com mais frequência. 

Mais um exemplo

Em um processo de construção automatizado, todo o software, banco de dados e outros componentes são empacotados juntos.

Por exemplo, se você estiver desenvolvendo um aplicativo Java, a integração contínua empacotaria todos os arquivos estáticos do servidor da Web, como HTML, CSS e JavaScript, com o aplicativo Java e quaisquer scripts de banco de dados.

A integração contínua não apenas empacota todos os componentes de software e banco de dados, mas a automação também executará testes de unidade e outros tipos de testes. O teste dá feedback vital aos desenvolvedores de que suas alterações de código não quebraram nada.

<Leia também: saiba o que é e o que faz um desenvolvedor Back-End />

Quais são os benefícios da CI/CD?

Ele permite que as organizações enviem um software de forma rápida e eficiente. 

Além disso, CI/CD facilita um processo eficazmente, para colocar produtos no mercado mais rápido do que nunca, entregando código continuamente para a produção e garantindo um fluxo contínuo de novos recursos e correções de bugs por meio do método de entrega mais eficiente. 

Conheça mais vantagens da prática:

• Diminuição da tensão durante o desenvolvimento;
• Mais qualidade e segurança na aplicação;
• Afasta-se dos métodos tradicionais em cascata;
• Evita sobrecarregamento de engenheiros e desenvolvedores;
• Usuários mais satisfeitos;
• Organização com fator competitivo.

Quer aprender mais? Participe do evento DevOps & SRE Spreedy que será online e gratuito!

Você vai conhecer as tendências, desafios e as melhores práticas em DevOps e SRE. Também vai aprender interativamente com speakers feras no assunto e ainda pode aproveitar para expandir seu network.

Garanta sua vaga. Faça logo sua inscrição! 👉💻

Conheça também a assinatura Multi Mais e tenha acesso imediato aos cursos e bootcamps oferecidos pela Faculdade XP! Você poderá estudar onde e quando quiser!

Ao criar um produto ou projeto do zero é importante se atentar a alguns pontos para que os usuários consigam utilizar o software da melhor maneira e sem erros. Dentro desse desenvolvimento, um aspecto importante é investir no user story. No entanto, somente através dele não é possível criar uma boa estrutura que atenda as necessidades dos usuários, também é preciso investir na metodologia INVEST. 

Ela é uma técnica complementar ao user story, que quando bem administrada potencializa os efeitos de um desenvolvimento de software que utiliza das metodologias Agile. 📈

Não se esqueça que hoje surgem cada vez mais ideias, conceitos e práticas capazes de implantar processos mais ágeis. Portanto, para que isto seja eficaz, será abordada uma das principais características, o Invest, que possibilita administrar resultados de valor agregado. ⭐

Confira neste artigo os principais detalhes sobre a metodologia Invest e por que você deve aplicá-la no seu dia a dia. Continue a leitura e descubra! 👇

O que é User Story (História de Usuário)?

Chamada de história do usuário, é uma técnica a fim de descrever em uma linguagem simples, curta e direta as necessidades de um usuário para o desenvolvimento de um software para produto. 

Ela funciona como uma espécie de documento que retrata as principais informações dos usuários interessados para que se atendam todas as expectativas na entrega do produto. 

Por exemplo: se você compra um celular e ele vem faltando um botão de fazer chamada, foi um erro dos desenvolvedores que não lembraram da necessidade do usuário em fazer a ligação. 

Investir no user story ajuda a prevenir esses casos, além de contribuir para uma melhor experiência do cliente. 😉

Mas o que é e onde entra a técnica INVEST na história de usuário? Leia a seguir. 👇

O que é a metodologia INVEST?

É uma técnica que acompanha o user story. Ela se trata de uma lista de qualificações para padronizar a quebra de histórias do usuário, alimentando a cadeia de valor do squad no Scrum. Ou seja, auxilia na criação das histórias de usuário, a partir de critérios de aceitação para suas criações agregarem valor ao projeto.

Dessa forma, ela é divida em suas siglas, significando:

Independent (independente)

Significa que as histórias de usuário podem ser desenvolvidas de maneira independente uma da outra. Assim, em uma arquitetura de microservices há uma separação de domínios e responsabilidades. 

Esses cortes são validados em etapas e evitam fraudes, e funcionam sem depender de um responsável.

Um exemplo é a situação em que no processo de Onboarding, há uma peça de API que expõe o endpoint para um aplicativo mobile funcionar.

Negotiable (negociável)

Aqui a ideia é ser negociável para permitir a evolução do detalhamento do escopo durante toda a cadeia de valor. Ou seja, você usa uma história de forma flexível para que ela possa ser alterada durante todo o ciclo de vida dela.

Funciona como uma espécie de aprendizado contínuo que é preciso adaptar para criar a melhor solução para os problemas que necessitam de resolução.

Valuable (valor)

Nesse requisito a história deve gerar algum tipo de valor para o cliente final. Por isso, é preciso ter clareza sobre qual é este valor agregado à solução.

Por exemplo, em um cenário onde estamos criando uma solução de onboarding em um aplicativo deverão ser criadas diversas etapas de validação.

Estimable (estimável)

Neste é analisado o escopo proposto até se conseguir estimar o tempo necessário para finalizar o desenvolvimento.

Por isso, é necessário tempo para conseguir implementar as soluções. Você pode se perguntar:

• A especificação do que precisa fazer está clara?
• Todos os impedimentos para iniciar o desenvolvimento da história foram resolvidos?
• A história está small (pequena)? É possível quebrá-la mais um pouco em mais histórias?

Small (pequena) 

Não crie histórias que levem mais que uma sprint de 10 dias para serem desenvolvidas. 

Caso ocorra, o ideal é quebrar a história seguindo a técnica INVEST para ser desenvolvido em três dias, mas se não for possível quebrar neste nível não ultrapasse 10 dias. 

Vale ressaltar que user stories mal definidos e grandes podem se estender por meses.

Testable (testável)

Depois de tudo pronto é preciso sempre testar. Faça testes automatizados e/ou manuais que validem que os critérios de aceite foram implementados com sucesso.

Qual a função da metodologia INVEST nas user stories do Scrum?

Investir na metodologia INVEST com o user story vai te ajudar a ter histórias padronizadas e com mais qualidade. Além disso, existem outras vantagens, como: 

• O escopo e os requisitos de cada uma das peças ficam mais detalhados;
• A equipe terá mais flexibilidade para negociar o escopo e ter novos aprendizados durante toda a cadeia de valor; 
• A partir das entregas de parte do escopo vão gerando novas capacidades e a solução terá cada vez mais valor;
• As histórias de usuários serão desenvolvidas mais rápido e num espaço de tempo menor;
• Proporciona mais previsibilidade no trabalho, uma vez que estima-se o tempo de entrega das demandas; 
• Mais facilmente testada manualmente ou automatizada.

Portanto, utilizar o INVEST faz com que seja conferido se suas qualidades foram cumpridas, além de proporcionar mais assertividade ao seu user story com as necessidades dos usuários.

Como aplicar a metodologia INVEST?

Sabendo mais da parte conceitual, vem a prática. Você deve estar se perguntando como aplicar a metodologia INVEST, principalmente junto com o user story no seu desenvolvimento Agile. 🤔

👉 Existem duas etapas:

Product Backlog

Realizada através de técnicas como entrevistas, ela mapeia o Product Backlog de acordo com suas epics ou user story, como a imagem a seguir.

Diagrama de arquitetura

Ao mesmo tempo deste mapeamento ocorre fazer uma proposta inicial do diagrama de arquitetura mapeando todos os microsserviços que pretendemos criar, banco de dados, filas, integrações com outros domínios, etc. 

Afinal, como aprender sobre metodologia ágil?

Buscando trazer o mundo da agilidade para dentro da corporação, a metodologia INVEST veio para revolucionar o mercado de desenvolvimento Agile aprimorando o conceito e a execução de user story. 🤩

Ela funciona como uma espécie de diretriz para seguirmos e termos uma padronização na quebra de User Stories. No entanto, na prática do dia a dia são enfrentadas situações onde não será possível atender todos os requisitos. 

Logo, adotá-la vai ajudar sua cadeia de valor a ter uma fluidez maior e consequentemente um lead time cada vez menor. 😉

Gostou da ideia e quer se aprofundar mais sobre essa e outras metodologias ágeis para colocar em prática no seu trabalho como desenvolvedor? Confira um evento sobre Product Future e aprenda sobre gestão ágil e soluções voltadas para produtos. 🎯

Quando criamos ou desenvolvemos um software é necessário que ele esteja o mais explicado possível na linguagem do usuário para que possa ser utilizado da melhor maneira. Nesse sentido, usar o conceito de user story se torna essencial. Você já o conhecia?

Da tradução do inglês, história de usuários, ele faz parte de uma etapa de uma estrutura mais ágil de desenvolvimento e implementação de um produto em diversos setores, como na tecnologia da informação. 💻

Ele é um complemento do framework Scrum e deve ser sempre priorizado nas equipes que trabalham buscando entender quais problemas usuários estão enfrentando em um software e como encontrar o jeito mais simples de resolvê-los. 

Continue a leitura para entender mais detalhes sobre ele, bem como sua importância e como usá-lo no seu dia a dia. Vamos lá? 👇

O que é User Story?

Nada mais é do que uma ferramenta para definir e organizar os requisitos de um sistema e torná-lo mais legível para os usuários, sendo muito utilizada na metodologia ágil e no TI.

Mas como funciona? Quando se cria um produto ou projeto, é preciso que ele esteja o mais simples possível que um leigo possa entender, se não qual o sentido de tentar oferecê-lo aos seus clientes e usuários, certo? O user story que faz essa adaptação, sendo uma característica essencial do desenvolvimento Agile. 🤩

Podemos dizer que ele é uma espécie de promessa de conversa com o usuário, onde são colocadas especificações escritas utilizando linguagem de negócio, exemplificando, de forma simples, como uma pessoa usaria determinada funcionalidade de um produto. 😉

Assim, seu formato mais utilizado é esse:

👉 Como um <papel>, eu quero <desejo> de modo que <benefício>

Sendo:

• Papel: é a persona, para quem você está criando esse requisito;
• Desejo: intenção da persona, não os recursos que ela usa;
• Benefício: o que ele vai ganhar com isso? O que ele pretende alcançar?

Um exemplo seria:

Como um < Turista >, eu quero < Encontrar hotéis com vagas para entrada imediata em SP > de forma que < Não haja preocupação em reservar vagas em hotéis em caso de viagens de emergência>.

O trabalho do software é conseguir responder esses requisitos ao usuário, sem que ele tenha dificuldades. No entanto, somente com essa descrição, os desenvolvedores podem não conseguir transformar o objetivo da história em código e em testes de maneira otimizada. Por isso é utilizado o método de 3C’s, que será explicado mais adiante.

Por que é importante?

Para explicar isso imagine uma situação: você tem uma loja de carros e está vendendo 3 deles para pessoas diferentes. Só que na entrega um veio sem ar condicionado, outro sem sensor de ré e o outro veio completo, mas deu algum defeito no motor em menos de 5 km. 

Essas falhas podem ser resultados do não mapeamento das necessidades dos usuários e verificações de que o user story estaria mostrando caso tivesse sido bem feito.

Logo, funciona apenas como um tipo de lembrete de quais detalhes são necessários em um projeto, sendo que somente com ele não é possível desenvolver a história dos usuários, precisa de documentos e mais detalhes para isso.

No entanto, sua função é manter as necessidades dos usuários escritas de forma simples e ajudar a nortear a conversa entre as pessoas que construirão a funcionalidade que elas descrevem.

Assim, serve para priorizar os clientes e estimar o esforço necessário para realizar os objetivos propostos em um produto ou projeto.

Uma vez que o user story está documentado, o time de desenvolvimento sabe o porquê precisa desenvolver, afinal é uma maneira de gerar valor na sua execução. Portanto, ele é importante porque ajuda a definir o desejo do usuário final e aumenta a assertividade do trabalho de toda equipe. 🎯

Como escrever as histórias de usuários?

Primeiramente, o ponto mais relevante é entender que as histórias de usuários precisam ser simples e objetivas, para ser de fácil entendimento pelos desenvolvedores. 

Caso elas fiquem longas de modo que não encaixam em um quadro, é preciso refiná-las.

As user stories são descrições sobre a funcionalidade do seu produto e, por essa razão, é importante que elas representem verdadeiramente o ponto de vista do usuário. Assim, é necessário documentá-las em três blocos:

1. Entrega de valor

Aqui você deve pensar em como relacionar as user stories com uma entrega de valor. Como? Entender as razões pelas quais as histórias são importantes, o que usuários querem, entre outros. 

Respondida essa pergunta, você deve colocar na descrição dessa documentação o objetivo da funcionalidade principal em “Valor de Mercado”, “Redução de Risco” ou “Aumentar a Capacidade” e qual é o detalhe.

2. Narrativa do usuário

A segunda etapa é preciso criar a narrativa dessas necessidades do usuário. Daí você pode usar o template já citado, como:

• Como … [target da funcionalidade]
• Eu quero … [item desejado – título]
• Para que eu possa … [entrega de valor – job to be done daquilo]

3. Requisitos técnicos

No terceiro bloco você vai descrever os requisitos técnicos. Ou seja, vai colocar o que é preciso fazer para atender as necessidades e os objetivos propostos. 

Para isso, é possível utilizar a técnica de 7 dimensões do produto, que são:

1. Atores
2. Interfaces
3. Ação (história do usuário)
4. Dados
5. Regras de negócios
6. Ambiente
7. Qualidade (critérios de aceite)

Template de User Story 3C’s

Conforme brevemente mencionado em outro tópico, existe um conceito chamado de 3 C’s, que indica como construir a sua história de usuário.  

Vamos dizer que você é um Product Owner e, junto com o seu time Scrum, iniciam o seu Product Backlog e vão criar uma user story para cada item. Você deve usar:

Cartão

Aqui a ideia é a descrição da história de forma curta simples, tendo que caber tudo em um pequeno tamanho de cartão.

Assim, você deve definir: quem é o ator principal, a persona, qual o principal objetivo e o justificativa para ele.

Conversas

São como reuniões, em que todos do time debatem os planos para fazer acontecer o objetivo.

Nesse momento, é esperado que as pessoas, juntas, leiam a User Story e clarifiquem o máximo possível o entendimento do que é esperado, trazendo para discussão quais os possíveis problemas e soluções.

Confirmação

Sempre use critérios para identificar se a história está realmente concluída. Aqui são criados cenários que quando executados, mostram se obtiverem os resultados descritos e se está tudo certo, caso contrário será devolvido para o time de desenvolvimento corrigir os bugs.

INVEST

Além dos 3Cs, outro método importante é o INVEST, que vai ajudar a avaliar a qualidade da sua user story, que tem como objetivo usar cada sigla para ver se sua história tá indicando todos esses fatores: independente, negociável, valor, estimável, pequeno e testável.

Granularidade dos User Stories

Entendendo toda a parte conceitual, é o momento de saber sobre a estrutura. Existem alguns tipos de granularidade necessários para que os itens do backlog estejam refinados e elegíveis. São eles: 👇

A tríade Épico, Feature e User Story são os artefatos mais utilizados para estruturação de backlog de produto (product backlog) e para uso em backlog de sprints (sprint backlog), sendo:

User Story

A representação clara e informal que expressa a necessidade e/ou requisito de um potencial usuário. É  parte de um objetivo final. 

Funcionalidade

É quem agrupa um conjunto de histórias do usuário, com a função do Produto, da qual contém diversos requisitos funcionais com suas regras e exceções.

Épico

É uma grande parte do trabalho a ser realizado no Produto, onde se expressa de forma macro a necessidade global.

Afinal, como aprender a aplicar o User Story no dia a dia?

Portanto, quando olhamos como os produtos digitais impactam positivamente nosso cotidiano, percebemos que, muitas vezes, eles resolvem problemas de uma maneira bastante simples e de forma personalizada. E isso é graças ao uso do user story. 🖤

Assim, o Product Owner e seu time precisam entender quais as reais necessidades dos usuários na hora de criar um software, para que seja feito da melhor forma e com mais usabilidade para a UX do usuário. 📈

Neste artigo falamos um pouco sobre user story e a importância de uma boa granularidade, só que o assunto não se esgota aqui. 

👉 Se você quer aprender a colocar em prática em sua rotina em um setor de desenvolvimento e usar as melhores recomendações de uma metodologia ágil, confira este evento que preparamos sobre Product Future.