Cenário:
Olá a todos! Somos engenheiros de automação da empresa e apoiamos o desenvolvimento dos produtos da empresa: damos suporte a todo o pipeline de montagem, desde a confirmação de uma linha de código pelos desenvolvedores até a publicação de produtos acabados e licenças em servidores de atualização. Informalmente, somos chamados de engenheiros DevOps. Neste artigo, queremos falar sobre as etapas tecnológicas do processo de produção de software, como as vemos e como as classificamos.
Com o material você aprenderá sobre a complexidade de coordenar o desenvolvimento de vários produtos, sobre o que é um mapa tecnológico e como ele ajuda a agilizar e replicar soluções, quais são as principais etapas e etapas do processo de desenvolvimento, como são as áreas de responsabilidade entre DevOps e equipes em nossa empresa.
Sobre Caos e DevOps
Resumidamente, o conceito de DevOps inclui ferramentas e serviços de desenvolvimento, bem como metodologias e melhores práticas para sua utilização. Vamos destacar o global objetivo da implementação de ideias de DevOps em nossa empresa: trata-se de uma redução consistente no custo de produção e manutenção de produtos em termos quantitativos (horas-homem ou horas-máquina, CPU, RAM, Disco, etc.). A maneira mais fácil e óbvia de reduzir o custo geral de desenvolvimento no nível de toda a empresa é minimizando o custo de execução de tarefas seriais típicas em todas as etapas da produção. Mas quais são essas etapas, como separá-las do processo geral, em que etapas consistem?
Quando uma empresa desenvolve um produto, tudo fica mais ou menos claro: geralmente existe um roteiro e um esquema de desenvolvimento comuns. Mas o que fazer quando a linha de produtos se expande e há mais produtos? À primeira vista, eles têm processos e linhas de montagem semelhantes, e começa o jogo “encontrar X diferenças” em logs e scripts. Mas e se já houver mais de 5 projetos em desenvolvimento ativo e for necessário suporte para várias versões desenvolvidas ao longo de vários anos? Queremos reutilizar o máximo possível de soluções em pipelines de produtos ou estamos prontos para gastar dinheiro em um desenvolvimento exclusivo para cada um?
Como encontrar um equilíbrio entre exclusividade e soluções em série?
Essas perguntas começaram a surgir diante de nós cada vez com mais frequência desde 2015. O número de produtos cresceu e tentamos expandir ao mínimo nosso departamento de automação (DevOps), que dava suporte às linhas de montagem desses produtos. Ao mesmo tempo, queríamos replicar o maior número possível de soluções entre os produtos. Afinal, por que fazer a mesma coisa em dez produtos de maneiras diferentes?
Diretor de desenvolvimento: "Pessoal, podemos avaliar de alguma forma o que o DevOps faz pelos produtos?"
Nós: “Não sabemos, não fizemos essa pergunta, mas quais indicadores devem ser considerados?”
Diretor de desenvolvimento: "Quem sabe! Pensar…"
Como naquele famoso filme: "Estou em um hotel! .." - "Uh ... Você pode me mostrar o caminho?" Refletindo, chegamos à conclusão de que primeiro precisamos decidir sobre o estado final dos produtos; este se tornou nosso primeiro objetivo.
Então, como você analisa uma dúzia de produtos com equipes razoavelmente grandes de 10 a 200 pessoas e determina métricas mensuráveis ao replicar soluções?
1:0 a favor do Chaos, ou DevOps nas omoplatas
Começamos com uma tentativa de aplicar diagramas IDEF0 e vários diagramas de processos de negócios da série BPwin. A confusão começou após o quinto quadrado do próximo estágio do próximo projeto, e esses quadrados para cada projeto podem ser desenhados na cauda de uma longa píton com mais de 50 passos. Fiquei triste e tive vontade de uivar para a lua - não combinava em geral.
Tarefas típicas de produção
Modelar processos de produção é um trabalho muito complexo e trabalhoso: você precisa coletar, processar e analisar muitos dados de vários departamentos e cadeias de produção. Você pode ler mais sobre isso no artigo "".
Quando começamos a modelar nosso processo de produção, tínhamos um objetivo específico - transmitir a todos os funcionários envolvidos no desenvolvimento dos produtos de nossa empresa e aos gerentes de projeto:
- como os produtos e seus componentes, a partir do commit de uma linha de código, chegam ao cliente na forma de instaladores e atualizações,
- quais recursos são fornecidos para cada etapa de produção de produtos,
- quais serviços estão envolvidos em cada etapa,
- como são delimitadas as áreas de responsabilidade de cada etapa,
- quais contratos existem na entrada e na saída de cada estágio.
Ao clicar na imagem, ela será aberta em tamanho real.
O nosso trabalho na empresa está dividido em várias áreas funcionais. A direção da infraestrutura está empenhada na otimização da operação de todos os recursos "de ferro" do departamento, bem como na automação da implantação de máquinas virtuais e do ambiente nelas. A direção de monitoramento fornece controle de desempenho de serviço 24 horas por dia, 7 dias por semana; também fornecemos monitoramento como um serviço para desenvolvedores. A direção do fluxo de trabalho fornece às equipes ferramentas para gerenciar processos de desenvolvimento e teste, analisar o estado do código e obter análises de projetos. E, finalmente, a direção webdev fornece a publicação de lançamentos nos servidores de atualização GUS e FLUS, bem como o licenciamento de produtos usando o serviço LicenseLab. Para dar suporte ao pipeline de produção, configuramos e mantemos vários serviços de suporte diferentes para desenvolvedores (você pode ouvir histórias sobre alguns deles em encontros antigos: и). Também desenvolvemos ferramentas de automação interna, incluindo .
Nos últimos cinco anos, nosso trabalho acumulou muitas operações do mesmo tipo e rotina, e nossos desenvolvedores de outros departamentos vêm principalmente dos chamados tarefas típicas, cuja solução é total ou parcialmente automatizada, não causa dificuldades aos executores e não requer quantidades significativas de trabalho. Juntamente com as áreas de liderança, analisamos essas tarefas e conseguimos identificar categorias individuais de trabalho, ou etapas de produção, as etapas foram divididas em etapas indivisíveis, e várias etapas se somam cadeia de processo de produção.
O exemplo mais simples de uma cadeia tecnológica são as etapas de montagem, implantação e teste de cada um de nossos produtos dentro da empresa. Por sua vez, por exemplo, o estágio de construção consiste em muitas etapas típicas separadas: download de fontes do GitLab, preparação de dependências e bibliotecas de terceiros, teste de unidade e análise de código estático, execução de um script de construção no GitLab CI, publicação de artefatos no repositório em Artifactory e geração de notas de lançamento através de nossa ferramenta interna ChangelogBuilder.
Você pode ler sobre tarefas típicas de DevOps em nossos outros artigos sobre Habré: ""E"".
Muitas cadeias de produção típicas formam processo de manufatura. A abordagem padrão para descrever processos é usar modelos IDEF0 funcionais.
Um exemplo de modelagem de um processo de IC de manufatura
Demos especial atenção ao desenvolvimento de projetos padrão para um sistema de integração contínua. Isso possibilitou a unificação dos projetos, destacando-se o chamado liberar esquema de compilação com promoções.
Veja como funciona. Todos os projetos parecem típicos: eles incluem a configuração de assemblies que se enquadram no repositório de instantâneos no Artifactory, após o que são implantados e testados em bancos de teste e, em seguida, promovidos ao repositório de lançamento. O serviço Artifactory é um ponto de distribuição único para todos os artefatos de construção entre equipes e outros serviços.
Se simplificarmos e generalizarmos muito nosso esquema de liberação, ele incluirá as seguintes etapas:
- montagem de produto multiplataforma,
- implantação em bancadas de teste,
- executando testes funcionais e outros,
- promover compilações testadas para liberar repositórios no Artifactory,
- publicação de compilações de lançamento em servidores de atualização,
- entrega de montagens e atualizações para produção,
- iniciar a instalação e atualização do produto.
Por exemplo, considere o modelo tecnológico desse esquema de liberação típico (doravante simplesmente Modelo) na forma de um modelo IDEF0 funcional. Ele reflete as principais etapas do nosso processo de IC. Os modelos IDEF0 usam os chamados notação ICOM (Input-Control-Output-Mechanism) para descrever quais recursos são usados em cada estágio, com base em quais regras e requisitos o trabalho é executado, qual é a saída e quais mecanismos, serviços ou pessoas implementam um estágio específico.
Ao clicar na imagem, ela será aberta em tamanho real.
Via de regra, é mais fácil decompor e detalhar a descrição de processos em modelos funcionais. Mas à medida que o número de elementos aumenta, torna-se cada vez mais difícil entender algo neles. Mas no desenvolvimento real também existem etapas auxiliares: monitoramento, certificação de produtos, automação de processos de trabalho e outros. É por causa do problema de escala que abandonamos esta descrição.
Nascimento da esperança
Em um livro, encontramos antigos mapas soviéticos descrevendo processos tecnológicos (que, aliás, ainda são usados hoje em muitas empresas estatais e universidades). Espera, espera, porque nós também temos um fluxo de trabalho!.. Existem etapas, resultados, métricas, requisitos, indicadores e assim por diante... Por que não tentar aplicar fluxogramas também em nossos pipelines de produtos? Havia um sentimento: “É isso! Encontramos o fio certo, é hora de puxá-lo bem!
Em uma tabela simples, optamos por registrar os produtos por colunas, e as etapas tecnológicas e etapas do pipeline de produtos por linhas. Marcos são algo grande, como uma etapa de construção do produto. E as etapas são algo menor e mais detalhado, como a etapa de download do código-fonte para o servidor de compilação ou a etapa de compilação do código.
Nas interseções das linhas e colunas do mapa, colocamos os status de uma etapa e produto específicos. Para status, um conjunto de estados foi definido:
- Nenhuma informação - ou inapropriado. É preciso analisar a demanda de uma etapa do produto. Ou a análise já foi realizada, mas o estágio não é necessário no momento ou não se justifica economicamente.
- Postergado - ou não relevante no momento. É necessária uma etapa em andamento, mas não há forças para implementação este ano.
- Programado. A etapa está prevista para ser implementada ainda este ano.
- Implementado. O estágio no pipeline é implementado no volume necessário.
O preenchimento da tabela começou projeto a projeto. Primeiramente, as etapas e etapas de um projeto foram classificadas e seus status foram registrados. Em seguida, eles pegaram o próximo projeto, corrigiram os status nele e adicionaram os estágios e etapas que faltavam nos projetos anteriores. Como resultado, obtivemos as etapas e etapas de todo o nosso pipeline de produção e seus status em um projeto específico. Descobriu-se algo semelhante à matriz de competência do pipeline de produtos. Chamamos essa matriz de mapa tecnológico.
Com a ajuda do mapa tecnológico, coordenamos metrologicamente razoavelmente com as equipes os planos de trabalho para o ano e as metas que queremos alcançar juntos: quais etapas adicionamos ao projeto este ano e quais deixamos para depois. Além disso, no decorrer do trabalho, podemos ter melhorias nas etapas que concluímos para apenas um produto. Depois expandimos nosso mapa e introduzimos essa melhoria como uma etapa ou uma nova etapa, depois analisamos para cada produto e verificamos a viabilidade de replicar a melhoria.
Eles podem objetar a nós: “Isso tudo, é claro, bom, apenas com o tempo o número de etapas e estágios se tornará proibitivamente grande. Como ser?
Introduzimos descrições padronizadas e bastante completas dos requisitos de cada etapa e etapa, para que sejam compreendidos por todos da empresa da mesma forma. Com o tempo, à medida que as melhorias são introduzidas, uma etapa pode ser absorvida por outra etapa ou etapa e, então, elas "colapsarão". Ao mesmo tempo, todos os requisitos e nuances tecnológicas se enquadram nos requisitos do estágio ou etapa de generalização.
Como avaliar o efeito de replicar soluções? Usamos uma abordagem extremamente simples: atribuímos os custos iniciais de capital para a implementação de uma nova etapa aos custos gerais anuais do produto e depois dividimos por todos ao replicar.
Partes do desenvolvimento já são mostradas como marcos e etapas no mapa. Podemos influenciar na redução do custo do produto através da introdução de automação para etapas típicas. Em seguida, consideramos as mudanças nas características qualitativas, nas métricas quantitativas e no lucro recebido pelas equipes (em horas-homem ou horas-máquina de economia).
Mapa tecnológico do processo produtivo
Se pegarmos todas as nossas etapas e etapas, codificá-las com tags e expandi-las em uma cadeia, ela se tornará muito longa e incompreensível (apenas a própria "cauda python" de que falamos no início do artigo) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Estas são as etapas de construção de produtos [Build], implantando-os em servidores de teste [Deploy], testando [Test], promovendo compilações para liberar repositórios com base nos resultados dos testes [Promote], gerando e publicando licenças [License], publicando [ Publish] no servidor de atualização GUS e entrega aos servidores de atualização FLUS, instalação e atualização de componentes do produto na infraestrutura do cliente usando Gerenciamento de Configuração do Produto [Instalar], bem como coleta de telemetria [Telemetria] de produtos instalados.
Além deles, diferentes estágios podem ser distinguidos: monitoramento do estado da infraestrutura [InfMonitoring], controle de versão do código-fonte [SourceCodeControl], preparação do ambiente de construção [Prepare], gerenciamento de projetos [Workflow], fornecimento de ferramentas de comunicação às equipes [Comunicação], certificação do produto [ Certificação] e garantir a autossuficiência dos processos de CI [CISelfSufficiency] (por exemplo, independência de montagens da Internet). Dezenas de etapas em nossos processos nem serão consideradas, pois são muito específicas.
Será muito mais fácil entender e visualizar todo o processo produtivo se ele for apresentado na forma mapa tecnológico; trata-se de uma tabela na qual as etapas de produção individuais e as etapas decompostas do Modelo são escritas em linhas e em colunas uma descrição do que é feito em cada etapa ou etapa. A ênfase principal é colocada nos recursos que fornecem cada etapa e na delimitação de áreas de responsabilidade.
O mapa para nós é uma espécie de classificador. Reflete as grandes partes tecnológicas da produção de produtos. Graças a ele, ficou mais fácil para nossa equipe de automação interagir com os desenvolvedores e planejar em conjunto a implementação das etapas de automação, além de entender quais custos de mão de obra e recursos (humanos e hardware) serão necessários para isso.
Dentro de nossa empresa, o mapa é gerado automaticamente a partir do modelo jinja como um arquivo HTML normal e, em seguida, carregado no servidor GitLab Pages. Uma captura de tela com um exemplo de um mapa totalmente gerado pode ser visualizada .
Ao clicar na imagem, ela será aberta em tamanho real.
Em suma, o mapa tecnológico é um retrato generalizado do processo de produção, que reflete blocos claramente classificados com funcionalidade típica.
Estrutura do nosso roteiro
O mapa consiste em várias partes:
- Área do título - aqui é feita uma descrição geral do mapa, são introduzidos os conceitos básicos, são definidos os principais recursos e resultados do processo de produção.
- Dashboard - aqui você pode controlar a exibição de dados para produtos individuais, é fornecido um resumo das etapas implementadas e etapas em geral para todos os produtos.
- Mapa tecnológico - uma descrição tabular do processo tecnológico. No mapa:
- são dados todos os estágios, passos e seus códigos;
- descrições curtas e completas dos estágios são dadas;
- são indicados os insumos e serviços utilizados em cada etapa;
- são indicados os resultados de cada etapa e uma etapa separada;
- é indicada a área de responsabilidade de cada etapa e etapa;
- os recursos técnicos, como HDD (SSD), RAM, vCPU, e as horas-homem necessárias para suportar o trabalho nesta fase, tanto no momento atual - um fato, quanto no futuro - um plano, foram determinados;
- para cada produto, são indicadas quais etapas ou etapas tecnológicas para o mesmo foram implementadas, planejadas para implementação, irrelevantes ou não implementadas.
Tomada de decisão com base no mapa tecnológico
Depois de examinar o mapa, é possível tomar algumas ações - dependendo da função do funcionário na empresa (gerente de desenvolvimento, gerente de produto, desenvolvedor ou testador):
- entender quais etapas faltam em um produto ou projeto real e avaliar a necessidade de sua implementação;
- delimitar as áreas de responsabilidade entre vários departamentos, caso atuem em etapas distintas;
- acertar contratos nas entradas e saídas dos palcos;
- integrar seu estágio de trabalho no processo geral de desenvolvimento;
- avaliar com mais precisão a necessidade de recursos que fornecem cada uma das etapas.
Resumindo tudo o que foi dito acima
O roteamento é versátil, extensível e fácil de manter. É muito mais fácil desenvolver e manter uma descrição de processos nesta forma do que em um modelo estritamente acadêmico IDEF0. Além disso, uma descrição tabular é mais simples, familiar e melhor estruturada do que um modelo funcional.
Para a implementação técnica das etapas, temos uma ferramenta interna especial CrossBuilder - uma ferramenta de camada entre sistemas de CI, serviços e infraestrutura. O desenvolvedor não precisa cortar sua bicicleta: em nosso sistema de CI, basta executar um dos scripts (a chamada tarefa) da ferramenta CrossBuilder, que a executará corretamente, levando em consideração as características de nossa infraestrutura .
Resultados de
O artigo acabou sendo bastante longo, mas isso é inevitável ao descrever a modelagem de processos complexos. No final, gostaria de fixar brevemente nossas ideias principais:
- O objetivo de implementar as ideias de DevOps em nossa empresa é reduzir consistentemente o custo de produção e manutenção dos produtos da empresa em termos quantitativos (horas-homem ou horas-máquina, vCPU, RAM, disco).
- A forma de reduzir o custo total de desenvolvimento é minimizar o custo de execução de tarefas seriais típicas: etapas e etapas do processo tecnológico.
- Uma tarefa típica é uma tarefa cuja solução é totalmente ou parcialmente automatizada, não causa dificuldades para os executores e não requer custos significativos de mão de obra.
- O processo de produção é composto por etapas, as etapas são divididas em etapas indivisíveis, que são tarefas típicas de diferentes escalas e escopos.
- De tarefas típicas díspares, chegamos a cadeias tecnológicas complexas e modelos multiníveis do processo produtivo, que podem ser descritos por um modelo IDEF0 funcional ou por um mapa tecnológico mais simples.
- O mapa tecnológico é uma representação tabular das etapas e etapas do processo produtivo. O mais importante: o mapa permite ver todo o processo na sua totalidade, em grandes peças com possibilidade de o detalhar.
- Com base no mapa tecnológico, é possível avaliar a necessidade de introdução de etapas em um determinado produto, delimitar áreas de responsabilidade, pactuar contratos nas entradas e saídas de etapas e avaliar com mais precisão a necessidade de recursos.
Nos artigos a seguir, descreveremos com mais detalhes quais ferramentas técnicas são usadas para implementar determinados estágios tecnológicos em nosso mapa.
Autores do artigo:
- — Chefe de Automação (DevOps) na Positive Technologies
- - Deputado Chefe do Departamento de Automação (DevOps) da Positive Technologies
Fonte: habr.com