Imaxe:
Ola a todos! Somos enxeñeiros de automatización da empresa e apoiamos o desenvolvemento dos produtos da empresa: apoiamos todo o pipeline de montaxe desde o compromiso dunha liña de código polos desenvolvedores ata a publicación de produtos acabados e licenzas en servidores de actualización. Informalmente, chámannos enxeñeiros de DevOps. Neste artigo queremos falar das etapas tecnolóxicas do proceso de produción de software, como as vemos e como as clasificamos.
A partir do material aprenderás sobre a complexidade de coordinar o desenvolvemento de varios produtos, sobre que é un mapa tecnolóxico e como axuda a racionalizar e replicar solucións, cales son as principais etapas e pasos do proceso de desenvolvemento, como son as áreas de responsabilidade. entre DevOps e os equipos da nosa empresa.
Sobre Chaos e DevOps
Notemos brevemente que o concepto de DevOps inclúe ferramentas e servizos de desenvolvemento, así como metodoloxías e mellores prácticas para o seu uso. Destaquemos o global o obxectivo da implantación das ideas DevOps na nosa empresa: trátase dunha redución consistente do custo de produción e mantemento dos produtos en termos cuantitativos (horas home ou horas máquina, CPU, RAM, Disco, etc.). A forma máis sinxela e obvia de reducir o custo global de desenvolvemento a nivel de toda a empresa é minimizando o custo de realizar tarefas en serie típicas en todas as fases da produción. Pero cales son estas etapas, como separalas do proceso xeral, en que pasos consisten?
Cando unha empresa está a desenvolver un produto, todo está máis ou menos claro: normalmente hai unha folla de ruta xeral e un esquema de desenvolvemento. Pero que facer cando a liña de produtos se expande e hai máis produtos? A primeira vista, teñen procesos e liñas de montaxe similares e comeza o xogo de "buscar X diferenzas" nos rexistros e scripts. E se xa hai máis de 5 proxectos en desenvolvemento activo e se require soporte para varias versións desenvolvidas durante varios anos? Queremos reutilizar tantas solucións como sexa posible nos pipelines de produtos ou estamos preparados para gastar diñeiro en desenvolvemento único para cada unha?
Como atopar un equilibrio entre a singularidade e as solucións en serie?
Estas preguntas comezaron a xurdir cada vez máis a miúdo dende 2015. O número de produtos creceu e tentamos ampliar ao mínimo o noso departamento de automatización (DevOps), que admitía as liñas de montaxe destes produtos. Ao mesmo tempo, queriamos replicar o maior número de solucións posible entre produtos. Despois de todo, por que facer o mesmo en dez produtos de diferentes xeitos?
Director de Desenvolvemento: "Rapaces, podemos avaliar dalgún xeito o que fai DevOps para os produtos?"
Nós: "Non o sabemos, non fixemos tal pregunta, pero que indicadores hai que ter en conta?"
Director de Desenvolvemento: "Quen sabe! Pensa…”
Como naquela famosa película: "Estou nun hotel! .." - "Uh... Podes mostrarme o camiño?" Reflexionando, chegamos á conclusión de que primeiro hai que decidir sobre os estados finais dos produtos; este converteuse no noso primeiro obxectivo.
Entón, como analizas unha ducia de produtos con equipos bastante grandes de 10 a 200 persoas e determinas métricas medibles ao replicar solucións?
1:0 a favor do Chaos, ou DevOps nos omóplatos
Comezamos cun intento de aplicar diagramas IDEF0 e varios diagramas de procesos de negocio da serie BPwin. A confusión comezou despois do quinto cadrado da seguinte etapa do seguinte proxecto, e estes cadrados para cada proxecto pódense debuxar na cola dunha longa pitón con máis de 50 pasos. Sentínme triste e quería ouvear á lúa: non encaixaba en xeral.
Tarefas típicas de produción
Modelar procesos de produción é un traballo moi complexo e minucioso: cómpre recoller, procesar e analizar moitos datos de varios departamentos e cadeas de produción. Podes ler máis sobre isto no artigo "».
Cando comezamos a modelar o noso proceso de produción, tiñamos un obxectivo específico: transmitir a todos os empregados implicados no desenvolvemento dos produtos da nosa empresa e aos xestores de proxectos:
- como os produtos e os seus compoñentes, a partir do compromiso dunha liña de código, chegan ao cliente en forma de instaladores e actualizacións,
- que recursos se proporcionan para cada fase de produción de produtos,
- que servizos están implicados en cada etapa,
- como se delimitan as áreas de responsabilidade de cada etapa,
- que contratos existen na entrada e na saída de cada etapa.
Facendo clic na imaxe abrirase en tamaño completo
O noso traballo na empresa divídese en varias áreas funcionais. O departamento de infraestruturas dedícase a optimizar o funcionamento de todos os recursos de hardware do departamento, así como a automatizar o despregamento de máquinas virtuais e a contorna nelas. A dirección de vixilancia proporciona control sobre o rendemento dos servizos 24/7; Tamén ofrecemos seguimento como servizo para desenvolvedores. A dirección do fluxo de traballo proporciona aos equipos ferramentas para xestionar procesos de desenvolvemento e probas, analizar o estado do código e obter análises sobre proxectos. E, finalmente, a dirección webdev garante a publicación de versións nos servidores de actualización GUS e FLUS, así como a licenza de produtos mediante o servizo LicenseLab. Para apoiar o proceso de produción, configuramos e mantemos moitos servizos de soporte diferentes para desenvolvedores (podes escoitar historias sobre algúns deles nas reunións antigas: и). Tamén desenvolvemos ferramentas de automatización interna, incluíndo .
Nos últimos cinco anos, o noso traballo acumulou moitas operacións do mesmo tipo e rutinas, e os nosos desenvolvedores doutros departamentos proceden principalmente dos chamados tarefas típicas, cuxa solución está total ou parcialmente automatizada, non causa dificultades aos intérpretes e non require cantidades significativas de traballo. Xunto coas áreas líderes, analizamos este tipo de tarefas e puidemos identificar categorías individuais de traballo, ou fases de produción, as etapas foron divididas en pasos indivisibles, e varias etapas suman cadea do proceso de produción.
O exemplo máis sinxelo de cadea tecnolóxica son as fases de montaxe, implantación e proba de cada un dos nosos produtos dentro da empresa. Á súa vez, por exemplo, a fase de compilación consta de moitos pasos típicos separados: descarga de fontes de GitLab, preparación de dependencias e bibliotecas de terceiros, probas unitarias e análise de código estático, execución dun script de compilación en GitLab CI, publicación de artefactos no repositorio en GitLab. Artifactory e xeración de notas de lanzamento a través da nosa ferramenta interna ChangelogBuilder.
Podes ler sobre as tarefas típicas de DevOps nos nosos outros artigos sobre Habré: ""E"».
Fórmanse moitas cadeas de produción típicas proceso de fabricación. O enfoque estándar para describir procesos é utilizar modelos IDEF0 funcionais.
Un exemplo de modelado dun proceso de CI de produción
Prestamos especial atención ao desenvolvemento de proxectos estándar para un sistema de integración continua. Isto permitiu acadar a unificación de proxectos, destacando os denominados esquema de compilación de lanzamento con promocións.
Aquí tes como funciona. Todos os proxectos parecen típicos: inclúen a configuración de conxuntos que entran no repositorio de instantáneas en Artifactory, despois de que se despreguen e se proban en bancos de probas, e despois ascenden ao repositorio de versións. O servizo Artifactory é un punto de distribución único para todos os artefactos de construción entre equipos e outros servizos.
Se simplificamos e xeneralizamos moito o noso esquema de lanzamento, entón inclúe os seguintes pasos:
- creación de produtos multiplataforma,
- implantación en bancos de probas,
- realizar probas funcionais e outras,
- promovendo compilacións probadas para liberar repositorios en Artifactory,
- publicación de versións compiladas en servidores de actualización,
- entrega de montaxes e actualizacións de produción,
- iniciando a instalación e actualización do produto.
Por exemplo, considere o modelo tecnolóxico deste esquema de lanzamento típico (en diante simplemente Modelo) en forma de modelo IDEF0 funcional. Reflicte as principais etapas do noso proceso de CI. Os modelos IDEF0 usan o chamado notación ICOM (Input-Control-Output-Mechanism) para describir que recursos se utilizan en cada etapa, en función de que regras e requisitos se realiza o traballo, cal é a saída e que mecanismos, servizos ou persoas implementan unha determinada etapa.
Facendo clic na imaxe abrirase en tamaño completo
Como regra xeral, nos modelos funcionais é máis fácil descompoñer e detallar a descrición dos procesos. Pero a medida que o número de elementos crece, faise cada vez máis difícil entender algo sobre eles. Pero no desenvolvemento real tamén hai etapas auxiliares: seguimento, certificación de produtos, automatización de procesos de traballo e outras. É debido ao problema de escala que abandonamos esta descrición.
Nacemento da Esperanza
Nun libro, atopamos mapas soviéticos antigos que describen procesos tecnolóxicos (que, por certo, aínda se usan hoxe en moitas empresas e universidades estatais). Espera, espera, porque tamén temos un fluxo de traballo!... Hai etapas, resultados, métricas, requisitos, indicadores, etc., etc. Por que non intentas aplicar follas de fluxo tamén aos nosos produtos? Houbo unha sensación: "Isto é! Atopamos o fío axeitado, é hora de tiralo ben!
Nunha táboa sinxela, decidimos rexistrar os produtos por columnas e as fases tecnolóxicas e os pasos do pipeline de produtos por filas. Os fitos son algo grande, como un paso de construción dun produto. E os pasos son algo máis pequeno e detallado, como o paso de descargar o código fonte ao servidor de compilación ou o paso de compilar o código.
Nas interseccións das filas e columnas do mapa, poñemos os estados para unha etapa e produto específicos. Definíronse moitos estados para os estados:
- Non hai datos - ou impracticable. É necesario analizar a demanda dunha etapa do produto. Ou a análise xa foi realizada, pero a etapa non é actualmente necesaria ou non está xustificada economicamente.
- Aplazado - ou non relevante no momento. Precísase esta etapa, pero non hai enerxía para implementala este ano.
- Planificado. A etapa está prevista para a súa execución este ano.
- Implementado. A etapa na canalización implícase no volume necesario.
Cubrindo a táboa comezou proxecto por proxecto. En primeiro lugar, clasificáronse as fases e pasos dun proxecto e rexistráronse os seus estados. Despois tomaron o seguinte proxecto, arranxaron os estados nel e engadiron as etapas e pasos que faltaban en proxectos anteriores. Como resultado, obtivemos as etapas e pasos de todo o noso pipeline de produción e os seus estados nun proxecto específico. Resultou algo semellante á matriz de competencias do pipeline de produtos. Chamámoslle a tal matriz un mapa tecnolóxico.
Coa axuda do mapa tecnolóxico coordinamos razoadamente metroloxicamente cos equipos os plans de traballo para o ano e os obxectivos que queremos acadar entre todos: que etapas engadimos ao proxecto este ano e cales deixamos para máis adiante. Ademais, no transcurso do traballo, podemos ter melloras nas etapas que completamos para un só produto. Despois ampliamos o noso mapa e introducimos esta mellora como unha etapa ou un novo paso, despois analizamos para cada produto e descubrimos a viabilidade de replicar a mellora.
Poden opoñernos: “Isto é todo, por suposto, bo, só co tempo o número de pasos e etapas se fará prohibitivamente grande. Como ser?
Introducimos descricións estándar e bastante completas dos requisitos para cada etapa e paso, para que todos os integrantes da empresa os entendan do mesmo xeito. Co paso do tempo, a medida que se introducen melloras, un paso pode ser absorbido noutra etapa ou paso, e entón "colapso". Ao mesmo tempo, todos os requisitos e matices tecnolóxicos encaixan nos requisitos da etapa ou paso de xeneralización.
Como avaliar o efecto das solucións replicadas? Usamos un enfoque extremadamente sinxelo: atribuímos os custos de capital iniciais para a implementación dunha nova etapa aos custos xerais anuais do produto e, a continuación, repartimos entre todos durante a replicación.
Partes do desenvolvemento xa se mostran como fitos e pasos no mapa. Podemos influír na redución dos custos dos produtos mediante a introdución da automatización para as etapas típicas. Despois diso, calculamos os cambios nas características cualitativas, as métricas cuantitativas e o beneficio recibido polos equipos (en horas-hombre ou horas-máquina aforradas).
Mapa tecnolóxico do proceso produtivo
Se tomamos todas as nosas etapas e pasos, codificamos con etiquetas e expandimos nunha cadea, entón resultará moi longo e incomprensible (a mesma "cola de pitón" da que falamos ao comezo 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 son as etapas de construción de produtos [Construír], implantación dos servidores de proba [Implementación], proba [Proba], promoción de compilacións para liberar repositorios baseados nos resultados das probas [Promoción], xeración e publicación de licenzas [Licenza], publicación de [ Publicar] no servidor de actualización de GUS e entrega aos servidores de actualización de FLUS, instalación e actualización de compoñentes do produto na infraestrutura do cliente mediante a Xestión da configuración do produto [Instalar], así como a recollida de telemetría [Telemetría] dos produtos instalados.
Ademais delas, podemos distinguir etapas separadas: seguimento do estado da infraestrutura [InfMonitoring], xestión de versións do código fonte [SourceCodeControl], preparación do entorno de montaxe [Prepare], xestión de proxectos [Workflow], dotación de equipos de ferramentas de comunicación [ Comunicación], certificación de produto [Certificación] e garantía da autosuficiencia dos procesos de CI [CISelfSufficiency] (por exemplo, a independencia das montaxes de Internet). Nin sequera consideraremos ducias de pasos nos nosos procesos, porque son moi específicos.
Será moito máis doado entender e mirar todo o proceso de produción se se presenta no formulario mapa tecnolóxico; trátase dunha táboa na que se escriben en filas as fases de produción individuais e os pasos descompostos do Modelo, e en columnas unha descrición do que se fai en cada etapa ou paso. O principal énfase faise nos recursos que achega cada etapa, e na delimitación de ámbitos de responsabilidade.
Para nós, un mapa é unha especie de clasificador. Reflicte grandes partes tecnolóxicas da produción de produtos. Grazas a el, resultou máis doado para o noso equipo de automatización interactuar cos desenvolvedores e planificar conxuntamente a implementación das etapas de automatización, así como comprender que custos laborais e recursos (humanos e hardware) serán necesarios para iso.
Dentro da nosa empresa, o mapa xérase automaticamente a partir do modelo jinja como un ficheiro HTML normal e despois cárgase no servidor de GitLab Pages. Pódese ver unha captura de pantalla cun exemplo dun mapa totalmente xerado .
Facendo clic na imaxe abrirase en tamaño completo
En definitiva, un mapa tecnolóxico é unha imaxe xeneralizada do proceso produtivo, que reflicte bloques claramente clasificados e cunha funcionalidade estándar.
Estrutura da nosa folla de ruta
O mapa consta de varias partes:
- Área do título: aquí hai unha descrición xeral do mapa, introdúcense conceptos básicos, defínense os principais recursos e resultados do proceso de produción.
- Panel: aquí pode controlar a visualización de datos de produtos individuais, ofrécese un resumo das etapas implementadas e os pasos en xeral para todos os produtos.
- Mapa tecnolóxico - unha descrición en táboa do proceso tecnolóxico. No mapa:
- danse todas as etapas, pasos e os seus códigos;
- danse descricións breves e completas das etapas;
- indícanse os recursos de entrada e servizos utilizados en cada etapa;
- indícanse os resultados de cada etapa e un paso separado;
- indícase a área de responsabilidade para cada etapa e paso;
- determináronse os recursos técnicos, por exemplo, HDD (SSD), RAM, vCPU e as horas de traballo necesarias para soportar o traballo nesta fase, tanto o plan actual - feito como no futuro -;
- para cada produto, indícase que etapas tecnolóxicas ou pasos para o mesmo foron implantados, previstos para a súa implantación, irrelevantes ou non implantados.
Toma de decisións a partir do mapa tecnolóxico
Despois de examinar o mapa, é posible levar a cabo algunhas accións, dependendo do papel do empregado na empresa (xerente de desenvolvemento, director de produto, desenvolvedor ou probador):
- comprender que fases faltan nun produto ou proxecto real, e valorar a necesidade da súa implantación;
- delimitar as áreas de responsabilidade entre varios departamentos se traballan en diferentes etapas;
- acordar contratos nas entradas e saídas dos escenarios;
- integrar a súa etapa de traballo no proceso global de desenvolvemento;
- valorar con máis precisión a necesidade de recursos para apoiar cada etapa.
Resumindo todo o anterior
O enrutamento é versátil, extensible e fácil de manter. É moito máis doado desenvolver e manter unha descrición dos procesos nesta forma que nun modelo IDEF0 académico estrito. Ademais, unha descrición en táboa é máis sinxela, máis familiar e mellor estruturada que un modelo funcional.
Para a implementación técnica dos pasos, somos responsables dunha ferramenta interna especial chamada CrossBuilder, unha ferramenta de capas entre sistemas, servizos e infraestrutura de CI. O programador non necesita cortar a súa bicicleta: no noso sistema CI abonda con executar un dos scripts (a chamada tarefa) da ferramenta CrossBuilder, que o executará correctamente, tendo en conta as características da nosa infraestrutura.
Resultados de
O artigo resultou ser bastante longo, pero isto é inevitable cando se describe o modelado de procesos complexos. Ao final, gustaríame fixar brevemente as nosas ideas principais:
- O obxectivo de implementar ideas DevOps na nosa empresa é reducir de forma consistente o custo de produción e mantemento dos produtos da empresa en termos cuantitativos (horas persoais ou horas máquina, vCPU, RAM, disco).
- A forma de reducir o custo global do desenvolvemento é minimizar o custo de realizar tarefas típicas en serie: etapas e etapas do proceso tecnolóxico.
- Unha tarefa típica é unha tarefa cuxa solución está total ou parcialmente automatizada, non causa dificultades aos intérpretes e non require custos laborais significativos.
- O proceso de produción consta de etapas, as etapas divídense en pasos indivisibles, que son tarefas típicas de diferente escala e alcance.
- A partir de tarefas típicas dispares, chegamos a cadeas tecnolóxicas complexas e modelos multinivel do proceso produtivo, que poden ser descritos mediante un modelo IDEF0 funcional ou un mapa tecnolóxico máis sinxelo.
- O mapa tecnolóxico é unha representación tabular das etapas e pasos do proceso produtivo. O máis importante: o mapa permite ver todo o proceso na súa totalidade, en pezas grandes con posibilidade de detallalos.
- A partir do mapa tecnolóxico pódese valorar a necesidade de implantar etapas nun determinado produto, delimitar áreas de responsabilidade, acordar contratos de entradas e saídas de etapas e valorar con maior precisión a necesidade de recursos.
Nos seguintes artigos describiremos con máis detalle cales son as ferramentas técnicas que se utilizan para implementar determinadas etapas tecnolóxicas no noso mapa.
Autores do artigo:
- — Xefe do Departamento de Automatización (DevOps) en Positive Technologies
- - Deputado Xefe do Departamento de Automatización (DevOps) en Positive Technologies
Fonte: www.habr.com