Qual é a chave para configurar com êxito a Entrega Contínua em projetos? Trabalho bem coordenado de engenheiros de desenvolvimento, testes e infraestrutura. Obrigado, cap, como eles dizem :) Mas como colocá-lo em prática? Neste artigo, compartilharemos nossas melhores práticas sobre como organizar e implementar tudo isso.
Resumimos os princípios básicos em uma folha de dicas para nós mesmos e compartilhamos com você:
É improvável que engenheiros experientes aprendam algo novo com o artigo, mas esperamos que essas informações sejam úteis para iniciantes.
Quais são os requisitos e como eles são caracterizados
Cada projeto possui vários requisitos. É importante entender todos eles e não confundir.
Os requisitos de negócios determinam o que um sistema deve fazer da perspectiva dos negócios.
Por exemplo: o aplicativo deve permitir que o usuário venda ingressos e serviços adicionais para aumentar as vendas dos agentes.Os requisitos do usuário descrevem as metas e objetivos dos usuários que trabalharão no sistema para implementar os requisitos de negócios. Os requisitos do usuário geralmente são apresentados como casos do usuário.
Por exemplo: como usuário, preciso vender serviços por milhas.Requisitos funcionais - o que o sistema deve fazer. Determine a funcionalidade (comportamento) do sistema, que deve ser criada pelos desenvolvedores para que os usuários possam atender aos requisitos do usuário.
Requisitos não funcionais - como o sistema deve funcionar. Isso inclui requisitos de desempenho, qualidade, limitações, usabilidade, etc.
Tipos de tarefas e a ordem de sua descrição no Rastreador de problemas
Então, nós descrevemos os tipos de requisitos. Agora vamos dividi-los em tipos de tarefas, decifrar cada tipo e dizer como descrevê-lo corretamente.
Vamos começar com o mais épico, ou seja, com o épico.
Épica é uma tarefa comum, na qual todas as Histórias de Usuário são coletadas levando em consideração o tempo de desenvolvimento do serviço. Ele descreve o principal objetivo de um produto ou serviço. O principal objetivo da Epic é coletar tarefas e armazená-las em um único local, independentemente dos novos requisitos apresentados ao produto. A Epic é sempre mais do que uma história de usuário e pode nem se encaixar em uma iteração.
A solução do problema da Epic permite que você crie
MVP (produto viável mínimo) - o produto viável mínimo. Em outras palavras, o que precisa ser lançado para aprender e adaptar o produto com base no feedback dos usuários finais.
Qual a diferença entre a Epic e a User Story?
- Epic é apenas uma grande história de usuário, cuja marca registrada é a presença de um valor claro para o usuário.
- Começando a formar histórias de usuários, ou seja, coletando requisitos para um projeto, geralmente passamos de geral para particular - primeiro determinamos o conceito do projeto, selecionamos as principais pessoas (usuários do sistema), criamos uma lista dos principais recursos e, em seguida, esses recursos são detalhados em desejos separados - História do usuário.
A descrição da Epic é a seguinte:
- Título / Resumo Título - o nome da nova funcionalidade.
- Descrição / Descrição - é escrito de acordo com o padrão:
O papel do usuário (como tal usuário, eu ...) / Ação do usuário (quero fazer algo ...) / O resultado da ação (para obter um resultado que ...) / Interesse ou benefício (me permitirá obter tais e tais benefícios ...). - Um plano de implementação de amostra ou uma breve descrição das principais Histórias de Usuário que serão implementadas como parte da Epic with MVP.
- Anexos / Anexos - anexam correspondência, tecnologia e outras informações necessárias.
Como criar uma história de usuário e uma história técnica
A diferença entre a história do usuário e a história técnica é que a história técnica se refere a requisitos funcionais que devem ser levados em consideração e descritos na tarefa ao desenvolver o produto. E, no papel dos consumidores, aqui estão partes do sistema.
Descrevê-los é fácil. A principal coisa a lembrar é por que tudo isso está sendo feito.
A ordem da descrição da história do usuário é bastante padrão:
- Título / Resumo / Título - uma breve descrição da nova funcionalidade ou melhorias em um idioma compreensível para o cliente.
- Descrição / Descrição inclui o objetivo principal e o resultado desejado. Como, <função do usuário>, eu <quero obter>, com o objetivo de <resultado de ações>.
- Critérios de aceitação é uma lista de critérios de prioridade do produto. Ou seja, uma definição mensurável do que deve ser feito com o produto para que seja aceito pelas partes interessadas no projeto.
- Notas técnicas, modelos, layouts, layouts de página.
- Anexos / Anexos - todas as tecnologias necessárias, documentos, correspondência com o cliente.
Como descrever bugs
Quais informações devem ser indicadas ao relatar um bug:
1.
Título / Resumo / Título descreve brevemente a essência do erro e indica a localização do problema.
2. Descrição contém as seguintes etapas:
• como reproduzir as etapas de erro / reprodução,
• resultado atual,
Resultado esperado.
3.
Anexos / Anexos - todos os registros, capturas de tela, links necessários para o Kibana e outros arquivos.
4.
Ambiente - uma marca em que ambiente o erro é reproduzido e a categoria à qual o problema pertence. Por exemplo, um erro de interface do usuário, erro CORE, erro SWS etc.
5. A
prioridade permitirá que cada membro da equipe avalie a gravidade do problema e o gerente a veja na lista dos primeiros candidatos ao sprint.
E não se esqueça de definir o nível de prioridade correto :)
Agora que entendemos os princípios gerais do trabalho, mostraremos como organizar o pipeline de implantação.
Configuração do pipeline de implantação
Para acelerar a entrega de nossos serviços à produção, apresentamos um novo pipeline de implantação e usamos o GitFlow para trabalhar com código.
Para fazer isso de forma rápida e dinâmica, implantamos vários corredores do GitLab que executavam todas as tarefas push dos desenvolvedores. Graças à abordagem do GitLab Flow, temos vários servidores: desenvolvimento, controle de qualidade, candidato a lançamento e produção.
A integração contínua começou a coletar e executar testes para cada confirmação, executar testes de unidade e testes de integração, adicionar artefatos à entrega do aplicativo.
O desenvolvimento ocorre assim:
- O desenvolvedor adiciona novas funcionalidades em uma ramificação separada (ramificação de recurso). Depois disso, ele cria uma solicitação para mesclar sua ramificação com a ramificação principal de desenvolvimento (Merge Request to Develop).
- Outros desenvolvedores examinam a solicitação de mesclagem, aceitam (ou não) e corrigem os comentários. Após a mesclagem, um ambiente especial se desdobra na ramificação do tronco, na qual são realizados testes para elevar o ambiente.
- Quando todas essas etapas são concluídas, o engenheiro de controle de qualidade realiza as alterações em sua ramificação "QA" e realiza os testes.
- Se o engenheiro de controle de qualidade concordar com o trabalho realizado, as alterações vão para a filial Release-Candidate e são implantadas em um ambiente acessível a usuários externos. Nesse ambiente, o cliente aceita e verifica as tecnologias. Depois destilamos tudo para a produção.
Se, em algum momento, houver erros, é nesse ramo que os solucionamos, após o qual publicamos o resultado no Develop.
Também criamos um pequeno plugin para que o Redmine possa nos dizer em que estágio o recurso está. Isso ajuda os testadores a avaliar em que estágio você precisa se conectar à tarefa e os desenvolvedores a corrigir erros. Então eles vêem em que estágio a falha ocorreu, podem ir para um ramo específico e reproduzi-lo lá.
Esperamos que você ache útil.