Imagem: UnsplashOlá pessoal! Somos engenheiros de automação da
Positive Technologies e apoiamos o desenvolvimento de produtos da empresa: apoiamos toda a linha de montagem, desde desenvolvedores que comprometem uma linha de código até a publicação de produtos acabados e licenças em servidores de atualização. Informalmente, somos chamados de engenheiros de DevOps. Neste artigo, queremos falar sobre os estágios tecnológicos do processo de produção de software, sobre como os vemos e como os classificamos.
A partir do material, você aprenderá sobre a complexidade da coordenação do desenvolvimento de vários produtos, sobre o que é um fluxo de trabalho e como ele ajuda a organizar e replicar soluções, quais são os principais estágios e etapas do processo de desenvolvimento, como as responsabilidades são divididas entre os DevOps e as equipes de nossa empresa.
Sobre o Caos e DevOps
Observe brevemente que o conceito de DevOps inclui ferramentas e serviços de desenvolvimento, bem como metodologias e práticas recomendadas para seu uso. Destacaremos o
objetivo global da introdução das idéias de DevOps em nossa empresa: essa é 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 simples e óbvia de reduzir o custo total de desenvolvimento no nível da empresa é
minimizar o custo de executar tarefas seriais típicas em todas as etapas da produção. Mas quais são essas etapas, como distingui-las do processo geral, em quais etapas elas consistem?
Quando uma empresa desenvolve um único produto, tudo fica mais ou menos claro: geralmente há um roteiro e um esquema de desenvolvimento comuns. Mas o que fazer quando a linha de produtos se expandir e houver mais produtos? À primeira vista, eles têm processos e linhas de montagem semelhantes e o jogo "encontra X diferenças" nos logs e scripts começa. E se já existem mais de 5 projetos em desenvolvimento ativo e você precisa de suporte para várias versões desenvolvidas ao longo de vários anos? Queremos reutilizar o número máximo possível de soluções em transportadores de produtos ou estamos prontos para gastar dinheiro em um desenvolvimento exclusivo para cada um?
Como encontrar um equilíbrio entre exclusividade e serialidade de soluções?
Esses problemas começaram a surgir diante de nós com mais frequência desde 2015. O número de produtos cresceu e tentamos minimizar a expansão do nosso departamento de automação (DevOps), que suportava as linhas de montagem desses produtos. Ao mesmo tempo, eu queria o maior número possível de soluções para replicar entre 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 nos fizemos essa pergunta, mas que indicadores devem ser considerados?"
Diretor de Desenvolvimento : “E quem sabe! Pense ... "
Como no famoso filme: "Para o meu hotel! .." - "Uh ... você vai mostrar o caminho?" Pensando, chegamos à conclusão de que primeiro você precisa decidir sobre os estados finais dos produtos; esse foi nosso primeiro objetivo.
Então, como você analisa uma dúzia de produtos com equipes grandes o suficiente 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 a quinta caixa da próxima etapa do próximo projeto, e esses quadrados para cada projeto podem ser desenhados na cauda de um longo python com mais de 50 etapas. Fiquei triste e queria uivar para a lua - não se encaixava em geral.
Tarefas típicas de produção
Modelar processos de produção é uma tarefa muito complexa e minuciosa: você precisa coletar, processar e analisar muitos dados em vários departamentos e cadeias de produção. Você pode ler mais sobre isso no artigo "
Modelagem de processos de produção em empresas de TI ".
Quando começamos a modelar nosso processo de produção, buscamos um objetivo específico - transmitir a cada funcionário envolvido no desenvolvimento dos produtos da empresa e aos gerentes de projeto:
- como os produtos e seus componentes, a partir de uma linha de código, chegam ao cliente na forma de instaladores e atualizações,
- que recursos são fornecidos para cada etapa da produção de produtos,
- quais serviços estão envolvidos em cada etapa,
- como as áreas de responsabilidade são diferenciadas para cada estágio,
- quais contratos existem na entrada e na saída de cada estágio.
Ao clicar na imagem abrirá em tamanho realNosso trabalho na empresa é dividido em várias áreas funcionais. A direção da infraestrutura é otimizar a operação de todos os recursos "de ferro" do departamento, além de automatizar a implantação de máquinas virtuais e o ambiente nelas. A direção de monitoramento fornece monitoramento de integridade do serviço 24/7; Também fornecemos monitoramento como serviço para desenvolvedores. A direção do fluxo de trabalho fornece às equipes ferramentas para gerenciar processos de desenvolvimento e teste, analisar o status do código e obter análises de projetos. E, finalmente, o webdev fornece lançamentos de publicação nos servidores de atualização GUS e FLUS, além de licenciar produtos usando o serviço LicenseLab. Para dar suporte ao pipeline de produção, configuramos e mantemos muitos serviços de suporte diferentes para desenvolvedores (você pode ouvir histórias sobre alguns deles nas antigas mitaps:
Op! DevOps! 2016 e
Op! DevOps! 2017 ). Também desenvolvemos ferramentas internas de automação, incluindo
soluções de código aberto .
Nos últimos cinco anos, muitas operações do mesmo tipo e de rotina acumularam-se em nosso trabalho, e de nossos desenvolvedores de outros departamentos vêm principalmente as chamadas
tarefas padrão , cuja solução é automatizada no todo ou em parte, não causa dificuldades para os artistas e não exige quantidades significativas de trabalho. Juntamente com as direções principais, analisamos essas tarefas e conseguimos distinguir determinadas categorias de trabalho ou
estágios de produção , dividimos os estágios em etapas indivisíveis e a
cadeia tecnológica da
produção consiste em várias etapas.
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 na empresa. Por sua vez, por exemplo, a fase de construção consiste em várias etapas típicas separadas: baixar a fonte do GitLab, preparar dependências e bibliotecas de terceiros, teste de unidade e análise de código estático, executar um script de construção no GitLab CI, publicar artefatos na loja no Artifactory e gerar notas de versão por meio de nossa ferramenta interna ChangelogBuilder.
Você pode ler sobre tarefas típicas do DevOps em outros artigos sobre Habré: “
Experiência pessoal: como é o sistema de integração contínua ” e “
Automação de processos de desenvolvimento: como implementamos as idéias do DevOps em tecnologias positivas ”.
Muitas cadeias de produção típicas formam o
processo de produção . Uma abordagem padrão para descrever processos é usar modelos IDEF0 funcionais.
Um exemplo de modelagem de um processo de IC de produção
Damos especial atenção ao desenvolvimento de projetos-modelo para um sistema de integração contínua. Isso nos permitiu alcançar a unificação dos projetos, destacando o chamado
esquema de montagem de lançamentos com avanços .
Aqui está como isso funciona. Todos os projetos parecem típicos: incluem a configuração de montagens que se enquadram no repositório de capturas instantâneas no Artifactory, após o qual são implementadas e testadas em bancos de teste e depois promovidas para o repositório de liberação. O serviço Artefato é o ponto único de distribuição de todos os artefatos de construção entre equipes e outros serviços.
Se simplificarmos e generalizarmos bastante nosso esquema de lançamento, ele incluirá as seguintes etapas:
- montagem de produtos multiplataforma,
- implantação para testar suportes,
- executando testes funcionais e outros,
- promoção de compilações testadas para liberar repositórios no Artifactory,
- Publicar compilações de versão para atualizar servidores,
- entrega de montagens e atualizações de produção,
- Ative as atualizações de instalação e produto.
Por exemplo, considere o modelo tecnológico desse esquema de liberação típico (a seguir denominado simplesmente Modelo) na forma de um modelo IDEF0 funcional. Ele reflete os principais estágios do nosso processo de IC. Os modelos IDEF0 usam a chamada
notação ICOM (mecanismo de entrada-controle-saída) para descrever quais recursos são usados em cada estágio, com base em quais regras e requisitos, o que é feito, o que é produzido e quais mecanismos, serviços ou pessoas implementar um estágio específico.
Ao clicar na imagem abrirá em tamanho realComo regra, em modelos funcionais é mais fácil decompor e detalhar a descrição dos processos. Mas, com o aumento do número de elementos, entender neles algo se torna cada vez mais difícil. 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 essa descrição.
O nascimento da esperança
Em um livro, me deparei com velhos mapas soviéticos descrevendo processos tecnológicos (que, aliás, são usados agora em muitas empresas e universidades estatais). Espere, espere, porque também temos um processo tecnológico! .. Existem estágios, resultados, métricas, requisitos, indicadores e assim por diante ... Por que não tentar aplicar mapas tecnológicos aos nossos transportadores de produtos? Havia um sentimento: “Aqui está! Encontramos o fio certo, é hora de puxá-lo bem! ”
Em uma tabela simples, decidimos consertar os produtos em colunas e nas linhas etapas e etapas tecnológicas do transportador de produtos. Etapas - isso é algo grande, por exemplo, a fase de montagem do produto. E as etapas são menores e mais detalhadas, por exemplo, a etapa de baixar o código-fonte para o servidor de compilação ou a etapa de compilar o código.
Nas interseções de linhas e colunas do mapa, colocamos os status de um estágio e produto específicos. Para status, muitos estados foram definidos:
- Sem dados - ou impraticáveis. É necessário realizar uma análise da demanda pelo estágio no produto. A análise já foi realizada, mas atualmente o estágio não é necessário ou não é economicamente justificado.
- Adiado - ou irrelevante no momento. É necessário um estágio no transportador, mas este ano não há forças para implementação.
- Agendado . O estágio está planejado para ser implementado para este ano.
- Está implementado . O estágio no transportador é implementado no volume necessário.
O preenchimento da tabela começou no projeto. No início, as etapas e etapas de um projeto foram classificadas e os status foram registrados para eles. Em seguida, eles pegaram o próximo projeto, registraram os status e adicionaram as etapas e etapas ausentes nos projetos anteriores. Como resultado, obtivemos as etapas e etapas de todo o transportador de produção e seus status em um projeto específico. Aconteceu algo semelhante à matriz de competência do transportador de produtos. Chamamos essa matriz de mapa tecnológico.
Usando o mapa tecnológico, coordenamos razoavelmente metrologicamente os planos e metas anuais de trabalho das equipes que queremos alcançar em conjunto: quais etapas adicionamos este ano ao projeto e quais deixamos para mais tarde. Além disso, no processo de trabalho, podemos receber melhorias nas etapas que realizamos para apenas um produto. Em seguida, expandimos nosso mapa e apresentamos essa melhoria como uma etapa ou uma nova etapa, depois analisamos cada produto e descobrimos a conveniência de replicar a melhoria.
Eles podem se opor a nós: “Isso é tudo, é claro, bom, somente com o tempo o número de etapas e estágios se torna proibitivamente grande. Como ser?
Introduzimos descrições padrão e suficientemente completas dos requisitos para cada estágio e etapa, para que sejam entendidos igualmente por todos dentro da empresa. Com o tempo, ao introduzir melhorias, uma etapa pode ser absorvida em outra etapa ou etapa - então elas "entrarão em colapso". Ao mesmo tempo, todos os requisitos e nuances tecnológicas se encaixam nos requisitos de um estágio ou etapa de generalização.
Como avaliar o efeito de replicar decisões? Utilizamos uma abordagem extremamente simples: atribuímos os custos iniciais de capital para a implementação do novo estágio aos custos gerais anuais de alimentos e os dividimos em todos na replicação.
Partes do desenvolvimento já são refletidas como etapas e etapas no mapa. Podemos influenciar a redução dos custos do produto através da introdução da automação para estágios típicos. Depois disso, 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).
Fluxograma do processo
Se seguirmos todos os nossos estágios e etapas, codificarmos com tags e expandirmos em uma cadeia, será muito longo e incompreensível (apenas a "cauda de píton" de que falamos no começo 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]
Estes são os estágios de montagem dos produtos [Build], implantando-os nos servidores de teste [Deploy], testando [Test], promovendo assemblies para liberar repositórios com base no teste [Promover], 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 o Gerenciamento de Configuração do Produto [Instalar], bem como a coleta de telemetria [Telemetria] dos produtos instalados.
Além deles, há estágios separados: monitoramento do estado da infraestrutura [InfMonitoring], controle de versão do código-fonte [SourceCodeControl], preparação do ambiente de montagem [Prepare], gerenciamento de projetos [Workflow], fornecimento às equipes de ferramentas de comunicação [Comunicação], certificação do produto [Certification] e fornecimento auto-suficiência de processos de IC [CISelfSufficiency] (por exemplo, independência de assemblies da Internet). Nem sequer consideraremos dezenas de etapas em nossos processos, porque elas são muito específicas.
Será muito mais fácil entender e dar uma olhada em todo o processo de produção, se apresentado na forma de um
mapa tecnológico ; Essa é uma tabela na qual as etapas de produção individuais e as etapas decompostas do Modelo são gravadas em linhas e as colunas descrevem o que é feito em cada etapa ou etapa. A ênfase principal é colocada nos recursos que fornecem cada estágio e na delimitação das áreas de responsabilidade.
O mapa para nós é uma espécie de classificador. Reflete as grandes partes tecnológicas da produção de alimentos. Graças a isso, ficou mais fácil para a nossa equipe de montadoras interagir com os desenvolvedores e planejar em conjunto a implementação das etapas de automação, além de entender que mão de obra e recursos (humanos e ferro) são necessários.
Dentro da nossa empresa, um mapa é gerado automaticamente a partir de um modelo jinja na forma de um arquivo HTML comum e, em seguida, é carregado no servidor de páginas do GitLab. Uma captura de tela com um exemplo de mapa totalmente gerado pode ser vista
aqui .
Ao clicar na imagem abrirá em tamanho realEm resumo, o fluxograma é uma imagem generalizada do processo de produção, na qual os blocos claramente classificados com funcionalidade típica são refletidos.
A estrutura do nosso roteamento
O mapa consiste em várias partes:
- Área de cabeçalho - aqui está uma descrição geral do mapa, conceitos básicos são introduzidos, recursos básicos e resultados do processo de produção são determinados.
- Painel de informações - aqui você pode controlar a exibição de dados para produtos individuais, fornece um resumo das etapas e etapas executadas para todos os produtos em geral.
- Mapa tecnológico - uma descrição tabular do processo tecnológico. No mapa:
- todas as etapas, etapas e seus códigos são fornecidos;
- É fornecida uma descrição breve e completa das etapas;
- Os recursos e serviços de entrada usados em cada estágio são indicados;
- são indicados os resultados de cada etapa e etapa individual;
- A área de responsabilidade para cada etapa e etapa é indicada;
- recursos técnicos, por exemplo, HDD (SSD), RAM, vCPU e horas de trabalho necessárias para apoiar o trabalho nesta fase, são identificados, tanto no momento atual - um fato quanto no futuro - um plano;
- para cada produto, é indicado quais etapas ou etapas tecnológicas foram implementadas, planejadas para a implementação, irrelevantes ou não implementadas.
Tomada de decisão baseada no mapa tecnológico
Após examinar o mapa, é possível executar algumas ações - dependendo da função do funcionário na empresa (gerente de desenvolvimento, gerente de produto, desenvolvedor ou testador):
- entender quais etapas estão faltando em um produto ou projeto real e avaliar a necessidade de sua implementação;
- diferenciar zonas de responsabilidade entre vários departamentos se eles trabalharem em diferentes estágios;
- acordar contratos nas entradas e saídas das etapas;
- integrar sua etapa do trabalho ao processo geral de desenvolvimento;
- avaliar com mais precisão a necessidade de recursos que forneçam cada um dos estágios.
Resumindo todas as opções acima
O roteamento é universal, extensível e fácil de manter. É muito mais fácil desenvolver e manter uma descrição dos processos dessa forma do que em um rigoroso modelo acadêmico IDEF0. Além disso, a descrição tabular é mais simples, mais familiar e melhor estruturada que o modelo funcional.
Pela implementação técnica das etapas, somos responsáveis pela ferramenta interna especial CrossBuilder - uma ferramenta intercalar entre sistemas, serviços e infraestrutura de CI. O desenvolvedor não precisa ver 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 peculiaridades de nossa infraestrutura.
Sumário
O artigo acabou sendo bastante longo, mas isso é inevitável ao descrever a modelagem de processos complexos. No final, quero corrigir brevemente nossas principais idéias:
- O objetivo de introduzir as idéias de DevOps em nossa empresa é uma redução consistente no custo de produção e manutenção dos produtos da empresa em termos quantitativos (horas-homem ou horas-máquina, vCPU, RAM, disco).
- Uma maneira de reduzir o custo total do desenvolvimento é minimizar o custo da execução de tarefas seriais típicas: estágios e etapas do processo tecnológico.
- Uma tarefa típica é uma tarefa cuja solução é automatizada no todo ou em parte, não causa dificuldades para os artistas e não exige custos de mão-de-obra significativos.
- O processo de produção consiste em etapas, as etapas são divididas em etapas indivisíveis, tarefas típicas de diferentes escalas e volumes.
- A partir de tarefas típicas díspares, chegamos a complexas cadeias tecnológicas e modelos multiníveis do processo de produção, que podem ser descritos por um modelo funcional IDEF0 ou um fluxograma mais simples.
- Um roteiro é uma apresentação tabular das etapas e etapas de um processo de fabricação. Mais importante: o mapa permite que você veja todo o processo, em pedaços grandes, com a possibilidade de detalhamento.
- Com base no fluxograma, é possível avaliar a necessidade da implementação de estágios em um produto específico, delimitar áreas de responsabilidade, acordar contratos para as entradas e saídas dos estágios e avaliar com mais precisão a necessidade de recursos.
Nos artigos a seguir, falaremos com mais detalhes sobre quais ferramentas técnicas são usadas para implementar certas etapas tecnológicas em nosso mapa.
Autores do artigo: