Hoxe, a maioría dos produtos de software desenvólvense en equipos. As condicións para o desenvolvemento exitoso do equipo pódense representar en forma de diagrama sinxelo.

Despois de escribir o código, debes asegurarte de que:

1. Traballando.
2. Non rompe nada, incluído o código que escribiron os teus compañeiros.

Se se cumpren ambas as condicións, estás no camiño do éxito. Para comprobar facilmente estas condicións e non desviarse do camiño rendible, creamos a Integración Continua.

CI é un fluxo de traballo no que integras o teu código no código global do produto coa maior frecuencia posible. E non só te integras, senón que tamén verificas constantemente que todo funciona. Xa que cómpre comprobar moito e moitas veces, paga a pena pensar na automatización. Podes comprobar todo manualmente, pero non deberías facelo, e aquí tes por que.

• Querida xente. Unha hora de traballo de calquera programador é máis cara que unha hora de traballo de calquera servidor.
• A xente comete erros. Polo tanto, poden xurdir situacións cando as probas se executaron na rama incorrecta ou se compilaron a confirmación incorrecta para os probadores.
• A xente é preguiceiro. De cando en vez, cando remato unha tarefa, xorde o pensamento: “Que hai que comprobar? Escribín dúas liñas: todo funciona! Creo que algúns de vós tamén tedes tales pensamentos ás veces. Pero sempre debes comprobar.

Como se implementou e desenvolveu a Integración Continua no equipo de desenvolvemento móbil de Avito, como pasaron de 0 a 450 compilacións ao día e que as máquinas de construción ensamblan 200 horas ao día, di Nikolai Nesterov (nnesterov) é participante en todos os cambios evolutivos da aplicación de Android CI/CD.

A historia baséase no exemplo dun comando de Android, pero a maioría dos enfoques tamén son aplicables en iOS.

Érase unha vez unha persoa que traballaba no equipo Avito Android. Por definición, non necesitaba nada de Integración Continua: non había con quen integrarse.

Pero a aplicación creceu, apareceron máis e máis tarefas novas e o equipo creceu en consecuencia. Nalgún momento, é hora de establecer formalmente un proceso de integración de código. Decidiuse usar o fluxo Git.

O concepto de fluxo de Git é ben coñecido: un proxecto ten unha rama de desenvolvemento común e, para cada función nova, os desenvolvedores cortan unha rama separada, comprométense a ela, empuxan e, cando queren combinar o seu código na rama de desenvolvemento, abren un solicitude de extracción. Para compartir coñecementos e discutir enfoques, introducimos a revisión do código, é dicir, os compañeiros deben comprobar e confirmar o código do outro.

Cheques

Ver código cos ollos é xenial, pero non o suficiente. Polo tanto, estanse introducindo comprobacións automáticas.

• En primeiro lugar, comprobamos Asemblea ARK.
• Moita cousa Probas Junit.
• Consideramos a cobertura do código, xa que estamos realizando probas.

Para entender como se deben executar estas comprobacións, vexamos o proceso de desenvolvemento en Avito.

Pódese representar esquemáticamente así:

• Un programador escribe código no seu portátil. Podes executar comprobacións de integración aquí mesmo, xa sexa cun gancho de confirmación ou simplemente executar comprobacións en segundo plano.
• Despois de que o programador empurrase o código, abre unha solicitude de extracción. Para que o seu código se inclúa na rama de desenvolvemento, é necesario pasar por unha revisión do código e recoller o número necesario de confirmacións. Podes activar comprobacións e compilacións aquí: ata que todas as compilacións teñan éxito, a solicitude de extracción non se pode combinar.
• Despois de combinar a solicitude de extracción e incluír o código no desenvolvemento, podes escoller un momento conveniente: por exemplo, pola noite, cando todos os servidores están libres, e realizar tantas comprobacións como queiras.

A ninguén lle gustaba realizar escaneos no seu portátil. Cando un programador rematou unha función, quere empurrala rapidamente e abrir unha solicitude de extracción. Se neste momento se lanzan algunhas comprobacións longas, isto non só non é moi agradable, senón que tamén ralentiza o desenvolvemento: mentres o portátil está comprobando algo, é imposible traballar con normalidade.

Gustounos moito facer comprobacións pola noite, porque hai moito tempo e servidores, podes andar por aí. Pero, desafortunadamente, cando se desenvolve o código de funcións, o programador ten moita menos motivación para corrixir os erros que CI atopou. Periódicamente púxenme a pensar cando miraba todos os erros atopados no informe da mañá que os solucionaría algún día despois, porque agora hai unha tarefa nova e interesante en Jira que só quero comezar a facer.

Se as verificacións bloquean unha solicitude de extracción, entón hai suficiente motivación, porque ata que as compilacións se volvan verdes, o código non se desenvolverá, o que significa que a tarefa non se completará.

Como resultado, escollemos a seguinte estratexia: realizamos o máximo conxunto posible de comprobacións pola noite e lanzamos as máis críticas delas e, o máis importante, as máis rápidas nunha solicitude de extracción. Pero non paramos aí; paralelamente, optimizamos a velocidade das comprobacións para transferilas do modo nocturno ás comprobacións de solicitudes.

Nese momento, todas as nosas compilacións completáronse con bastante rapidez, polo que simplemente incluímos a compilación ARK, as probas de Junit e os cálculos de cobertura de código como bloqueador para a solicitude de extracción. Acendemos, pensamos niso e abandonamos a cobertura do código porque pensamos que non o necesitabamos.

Levamos dous días configurar completamente o CI básico (en diante o tempo estimado é aproximado, necesario para a escala).

Despois diso, comezamos a pensar máis: estamos a verificar correctamente? Estamos a executar correctamente as versións das solicitudes de extracción?

Comezamos a compilación no último commit da rama desde a que se abriu a solicitude de extracción. Pero as probas deste commit só poden demostrar que o código que escribiu o programador funciona. Pero non proban que non rompese nada. De feito, cómpre comprobar o estado da rama de desenvolvemento despois de que se fusione unha función con ela.

Para iso, escribimos un script bash sinxelo premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Aquí todos os cambios máis recentes do desenvolvemento simplemente únense e únense á rama actual. Engadimos o script premerge.sh como primeiro paso en todas as compilacións e comezamos a comprobar exactamente o que queremos, é dicir integración.

Tardaron tres días en localizar o problema, atopar unha solución e escribir este script.

A aplicación desenvolveuse, apareceron máis e máis tarefas, o equipo creceu e premerge.sh ás veces comezaba a decepcionarnos. Develop tivo cambios conflitivos que romperon a construción.

Un exemplo de como isto ocorre:

Dous desenvolvedores comezan a traballar simultaneamente nas funcións A e B. O desenvolvedor da función A descobre unha función non utilizada no proxecto answer() e, coma un bo boy scout, quítao. Ao mesmo tempo, o desenvolvedor da función B engade unha nova chamada a esta función na súa rama.

Os desenvolvedores rematan o seu traballo e abren unha solicitude de extracción ao mesmo tempo. As compilacións lánzanse, premerge.sh comproba ambas as solicitudes de extracción sobre o estado de desenvolvemento máis recente; todas as comprobacións son verdes. Despois diso, a solicitude de extracción da característica A fusionase, a solicitude de extracción da característica B fusiona... ¡Boom! Desenvolver interrupcións porque o código de desenvolvemento contén unha chamada a unha función inexistente.

Cando non se vai desenvolver, si desastre local. Todo o equipo non pode recoller nada e envialo a proba.

Ocorreu que a maioría das veces traballaba en tarefas de infraestrutura: analítica, rede, bases de datos. É dicir, fun eu quen escribín aquelas funcións e clases que usan outros desenvolvedores. Debido a iso, atopeime moi a miúdo en situacións similares. Incluso tiven esta imaxe colgada por un tempo.

Dado que isto non nos conviña, comezamos a explorar opcións sobre como evitalo.

Como non romper desenvolver

A primeira opción: reconstruír todas as solicitudes de extracción cando se actualicen en desenvolvemento. Se, no noso exemplo, a solicitude de extracción coa característica A é a primeira que se inclúe no desenvolvemento, a solicitude de extracción da característica B reconstruirase e, en consecuencia, as comprobacións fallarán debido a un erro de compilación.

Para entender canto tempo levará isto, considere un exemplo con dous PR. Abrimos dous PR: dúas compilacións, dúas series de comprobacións. Despois de que o primeiro PR se fusione para desenvolver, o segundo debe ser reconstruído. En total, dous PR requiren tres series de comprobacións: 2 + 1 = 3.

En principio, está ben. Pero miramos as estatísticas, e a situación típica no noso equipo eran 10 PR abertas, e entón o número de comprobacións é a suma da progresión: 10 + 9 +... + 1 = 55. É dicir, aceptar 10. PRs, debes reconstruír 55 veces. E isto atópase nunha situación ideal, cando todas as comprobacións pasan por primeira vez, cando ninguén abre unha solicitude de extracción adicional mentres se procesan estas ducias.

Imaxínate como un programador que ten que ser o primeiro en facer clic no botón "fusionar", porque se un veciño fai isto, terás que esperar ata que todas as compilacións volvan pasar... Non, iso non funcionará. , ralentizará seriamente o desenvolvemento.

Segunda vía posible: recolle solicitudes de extracción despois da revisión do código. É dicir, abre unha solicitude de extracción, recolle o número necesario de aprobacións dos compañeiros, corrixe o necesario e, a continuación, inicia as compilacións. Se teñen éxito, a solicitude de extracción fusionarase en desenvolvemento. Neste caso, non hai reinicios adicionais, pero o feedback ralentízase moito. Como programador, cando abro unha solicitude de extracción, inmediatamente quero ver se vai funcionar. Por exemplo, se unha proba falla, cómpre solucionala rapidamente. No caso dunha compilación atrasada, a retroalimentación diminúe e, polo tanto, todo o desenvolvemento. Isto tampouco nos cabía.

Como resultado, só quedou a terceira opción: bicicleta. Todo o noso código, todas as nosas fontes almacénanse nun repositorio no servidor Bitbucket. En consecuencia, tivemos que desenvolver un complemento para Bitbucket.

Este complemento anula o mecanismo de combinación de solicitudes de extracción. O comezo é estándar: ábrese o PR, lánzanse todas as asembleas, complétase a revisión do código. Pero despois de que se complete a revisión do código e o programador decida facer clic en "fusionar", o complemento verifica o estado de desenvolvemento das comprobacións. Se o desenvolvemento se actualizou despois das compilacións, o complemento non permitirá que esa solicitude de extracción se fusione coa rama principal. Simplemente reiniciará as compilacións dun desenvolvemento relativamente recente.

No noso exemplo con cambios en conflito, tales compilacións fallarán debido a un erro de compilación. En consecuencia, o desenvolvedor da función B terá que corrixir o código, reiniciar as comprobacións e, a continuación, o complemento aplicará automaticamente a solicitude de extracción.

Antes de implementar este complemento, fixemos unha media de 2,7 revisións por solicitude de extracción. Co complemento houbo 3,6 lanzamentos. Isto nos conviña.

Paga a pena notar que este complemento ten un inconveniente: só reinicia a compilación unha vez. É dicir, aínda hai unha pequena ventá pola que se poden desenvolver cambios conflitivos. Pero a probabilidade diso é baixa e fixemos esta compensación entre o número de inicios e a probabilidade de fracaso. En dous anos só disparou unha vez, polo que probablemente non foi en balde.

Levamos dúas semanas escribir a primeira versión do complemento Bitbucket.

Novos cheques

Mentres tanto, o noso equipo seguiu medrando. Engadíronse novos cheques.

Pensamos: por que cometer erros se se poden evitar? E por iso implementaron análise de código estático. Comezamos con lint, que se inclúe no SDK de Android. Pero naquel momento non sabía como traballar co código Kotlin e xa tiñamos o 75% da aplicación escrita en Kotlin. Polo tanto, engadíronse os incorporados á pelusa Comprobacións de Android Studio.

Para iso, tivemos que facer moitas perversións: coller Android Studio, empaquetalo en Docker e executalo en CI cun monitor virtual, para que pense que se está a executar nun portátil real. Pero funcionou.

Tamén foi durante este tempo cando comezamos a escribir moito probas de instrumentación e implementado proba de captura de pantalla. Isto é cando se xera unha captura de pantalla de referencia para unha vista pequena separada, e a proba consiste en tomar unha captura de pantalla da vista e comparala co estándar directamente píxel por píxel. Se hai unha discrepancia, significa que o deseño foi mal nalgún lugar ou algo está mal nos estilos.

Pero as probas de instrumentación e as probas de capturas de pantalla deben executarse en dispositivos: en emuladores ou en dispositivos reais. Tendo en conta que hai moitas probas e que se fan con frecuencia, é necesaria unha granxa enteira. Comezar a túa propia granxa é moi laborioso, polo que atopamos unha opción preparada: Firebase Test Lab.

Laboratorio de probas de Firebase

Escolleuse porque Firebase é un produto de Google, o que significa que debería ser fiable e improbable que morra. Os prezos son razoables: 5 $ por hora de funcionamento dun dispositivo real, 1 $ por hora de funcionamento dun emulador.

Levou aproximadamente tres semanas implementar Firebase Test Lab no noso CI.

Pero o equipo continuou medrando e Firebase, por desgraza, comezou a decepcionarnos. Nese momento, non tiña ningún SLA. Ás veces, Firebase facíanos esperar ata que o número necesario de dispositivos estivese libres para probas e non comezaba a executalos inmediatamente, como queriamos. A espera na cola levou ata media hora, o que é moito tempo. Realizáronse probas de instrumentación en cada PR, os atrasos realmente retardaron o desenvolvemento e, a continuación, a factura mensual chegou cunha suma redonda. En xeral, decidiuse abandonar Firebase e traballar na casa, xa que o equipo creceu o suficiente.

Docker + Python + bash

Levamos a Docker, introducimos emuladores, escribimos un programa sinxelo en Python, que no momento oportuno mostra o número necesario de emuladores na versión requirida e detéñaos cando é necesario. E, por suposto, un par de scripts bash: onde estaríamos sen eles?

Levou cinco semanas crear o noso propio ambiente de proba.

Como resultado, para cada solicitude de extracción había unha extensa lista de comprobacións de bloqueo de fusión:

• montaxe ARK;
• probas Junit;
• Lint;
• comprobacións de Android Studio;
• Probas de instrumentación;
• Probas de captura de pantalla.

Isto evitou moitas posibles avarías. Tecnicamente todo funcionou, pero os desenvolvedores queixáronse de que a espera dos resultados era demasiado longa.

Canto tempo é demasiado? Cargamos datos de Bitbucket e TeamCity no sistema de análise e decatámonos diso tempo medio de espera 45 minutos. É dicir, un programador, ao abrir unha solicitude de extracción, espera unha media de 45 minutos para os resultados da compilación. Na miña opinión, isto é moito, e non se pode traballar así.

Por suposto, decidimos acelerar todas as nosas construcións.

Aceleremos

Vendo que as construcións adoitan estar nunha cola, o primeiro que facemos é comprou máis hardware - O desenvolvemento extensivo é o máis sinxelo. As compilacións deixaron de facer cola, pero o tempo de espera só diminuíu lixeiramente, porque algunhas comprobacións levaron moito tempo.

Eliminando comprobacións que tardan demasiado

A nosa integración continua podería detectar este tipo de erros e problemas.

• Non vai. CI pode detectar un erro de compilación cando algo non se crea debido a cambios en conflito. Como xa dixen, entón ninguén pode montar nada, o desenvolvemento detense e todos ponse nerviosos.
• Erro no comportamento. Por exemplo, cando a aplicación está construída, pero falla cando se preme un botón, ou o botón non se preme en absoluto. Isto é malo porque tal erro pode chegar ao usuario.
• Erro no deseño. Por exemplo, fai clic nun botón, pero moveuse 10 píxeles á esquerda.
• Aumento da débeda técnica.

Despois de mirar esta lista, decatámonos de que só os dous primeiros puntos son críticos. Queremos detectar estes problemas primeiro. Os erros no deseño descóbrense na fase de revisión do deseño e pódense corrixir facilmente. Tratar a débeda técnica require un proceso e unha planificación separados, polo que decidimos non probalo nunha solicitude de extracción.

En base a esta clasificación, sacudimos toda a lista de verificacións. Lint tachado e aprazou o seu lanzamento da noite para a mañá: só para que elaborase un informe sobre cantos problemas había no proxecto. Acordamos traballar por separado coa débeda técnica, e As comprobacións de Android Studio foron completamente abandonadas. Android Studio en Docker para realizar inspeccións parece interesante, pero causa moitos problemas no soporte. Calquera actualización das versións de Android Studio significa unha loita con erros incomprensibles. Tamén foi difícil soportar as probas de capturas de pantalla, porque a biblioteca non era moi estable e había falsos positivos. As probas de capturas de pantalla foron eliminadas da lista de verificación.

Como resultado, quedamos con:

• montaxe ARK;
• probas Junit;
• Probas de instrumentación.

Gradle remoto caché

Sen controis pesados, todo mellorou. Pero non hai límite para a perfección!

A nosa aplicación xa estaba dividida en preto de 150 módulos graduados. A caché remota de Gradle adoita funcionar ben neste caso, polo que decidimos probalo.

A caché remota de Gradle é un servizo que pode almacenar na caché artefactos de construción para tarefas individuais en módulos individuais. Gradle, en lugar de compilar realmente o código, usa HTTP para chamar á caché remota e preguntar se alguén xa realizou esta tarefa. Se si, simplemente descarga o resultado.

Executar a caché remota de Gradle é doado porque Gradle ofrece unha imaxe de Docker. Conseguimos facelo en tres horas.

Todo o que tiñas que facer era lanzar Docker e escribir unha liña no proxecto. Pero aínda que se pode lanzar rapidamente, vai levar moito tempo para que todo funcione ben.

Abaixo está o gráfico de fallas de caché.

Ao principio, a porcentaxe de fallos de caché era duns 65. Despois de tres semanas, conseguimos aumentar este valor ata o 20%. Resultou que as tarefas que recolle a aplicación de Android teñen estrañas dependencias transitivas, polo que Gradle perdeu a caché.

Ao conectar a caché, aceleramos moito a compilación. Pero ademais da montaxe, tamén hai probas de instrumentación, que levan moito tempo. Quizais non teñan que executarse todas as probas para cada solicitude de extracción. Para descubrilo, utilizamos a análise de impacto.

Análise de impacto

Nunha solicitude de extracción, recollemos git diff e atopamos os módulos Gradle modificados.

Ten sentido executar só probas de instrumentación que comproben os módulos modificados e todos os módulos que dependen deles. Non ten sentido facer probas para módulos veciños: o código alí non cambiou e nada se pode romper.

As probas de instrumentación non son tan sinxelas, porque deben estar situadas no módulo de Aplicación de nivel superior. Usamos heurísticas con análise de bytecode para comprender a que módulo pertence cada proba.

Actualizar o funcionamento das probas de instrumentación para que só probasen os módulos implicados levou unhas oito semanas.

As medidas para acelerar as inspeccións funcionaron con éxito. A partir dos 45 minutos subimos a uns 15. Xa é normal esperar un cuarto de hora para unha construción.

Pero agora os desenvolvedores comezaron a queixarse ​​de que non entenden que compilacións se están a lanzar, onde ver o rexistro, por que a compilación é vermella, que proba fallou, etc.

Os problemas coa retroalimentación retardan o desenvolvemento, polo que tentamos proporcionar información o máis clara e detallada posible sobre cada RP e construción. Comezamos con comentarios en Bitbucket para o PR, indicando que compilación fallara e por que, e escribimos mensaxes dirixidas en Slack. Ao final, creamos un panel de RRPP para a páxina cunha lista de todas as compilacións que se están executando actualmente e o seu estado: en cola, en execución, bloqueadas ou completadas. Podes facer clic na compilación e acceder ao seu rexistro.

Seis semanas dedicábanse a comentarios detallados.

Plans

Pasemos á historia recente. Resolto o problema dos comentarios, chegamos a un novo nivel: decidimos construír a nosa propia granxa de emuladores. Cando hai moitas probas e emuladores, son difíciles de xestionar. Como resultado, todos os nosos emuladores pasaron ao clúster k8s cunha xestión flexible de recursos.

Ademais, hai outros plans.

• Volver Lint (e outras análises estáticas). Xa estamos traballando nesta dirección.
• Executa todo nun bloqueador de PR probas de extremo a extremo en todas as versións do SDK.

Así, rastrexamos a historia do desenvolvemento da Integración Continua en Avito. Agora quero dar algúns consellos desde un punto de vista experimentado.

Советы

Se puidese dar só un consello sería este:

Por favor, teña coidado cos scripts de shell!

Bash é unha ferramenta moi flexible e poderosa, é moi cómodo e rápido para escribir guións. Pero podes caer nunha trampa con el e, por desgraza, caemos nela.

Todo comezou con scripts sinxelos que se executaron nas nosas máquinas de compilación:

#!/usr/bin/env bash
./gradlew assembleDebug

Pero, como sabes, todo se desenvolve e faise máis complicado co paso do tempo -executemos un script doutro, pasemos alí algúns parámetros- ao final tivemos que escribir unha función que determine en que nivel de anidamento de bash estamos agora en orde. para inserir as comiñas necesarias, para comezar todo.

Podes imaxinar os custos laborais para o desenvolvemento de tales guións. Aconsello que non caia nesta trampa.

Que se pode substituír?

• Calquera linguaxe de script. Escribe a Script Python ou Kotlin máis cómodo porque é programación, non scripts.
• Ou describa toda a lóxica de compilación no formulario Tarefas de graduación personalizadas para o teu proxecto.

Decidimos escoller a segunda opción, e agora estamos eliminando sistemáticamente todos os scripts bash e escribindo moitas tarefas de gradle personalizadas.

Consello # 2: almacena a infraestrutura en código.

É conveniente cando a configuración de integración continua non se almacena na interface de IU de Jenkins ou TeamCity, etc., senón en forma de ficheiros de texto directamente no repositorio do proxecto. Isto dá versións. Non será difícil revertir ou construír o código noutra rama.

Os scripts pódense almacenar nun proxecto. Que facer co medio ambiente?

Consello # 3: Docker pode axudar co medio ambiente.

Definitivamente axudará aos desenvolvedores de Android; iOS aínda non ten un, por desgraza.

Este é un exemplo dun ficheiro docker sinxelo que contén jdk e android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

Despois de escribir este ficheiro de Docker (contoche un segredo, non tes que escribilo, senón de tiralo xa feito desde GitHub) e montado a imaxe, obtén unha máquina virtual na que podes construír a aplicación e executa probas Junit.

As dúas razóns principais polas que isto ten sentido son a escalabilidade e a repetibilidade. Usando Docker, podes crear rapidamente unha ducia de axentes de compilación que terán exactamente o mesmo ambiente que o anterior. Isto facilita moito a vida dos enxeñeiros de CI. É bastante sinxelo empurrar o Android-sdk no docker, pero cos emuladores é un pouco máis difícil: terás que traballar un pouco máis (ou descargar o acabado de GitHub de novo).

Consello número 4: non esquezas que as inspeccións non se fan por inspeccións, senón por persoas.

O comentario rápido e, o máis importante, é moi importante para os desenvolvedores: que fallou, que proba fallou, onde podo ver o rexistro de compilación.

Consello #5: Sexa pragmático ao desenvolver a Integración Continua.

Comprenda claramente que tipos de erros quere evitar, cantos recursos, tempo e tempo de ordenador está disposto a gastar. As comprobacións que tardan demasiado poden, por exemplo, aprazarse durante a noite. E aqueles deles que collen erros non moi importantes deberían abandonarse por completo.

Consello # 6: Use ferramentas preparadas.

Agora hai moitas empresas que ofrecen CI na nube.

Esta é unha boa solución para equipos pequenos. Non necesitas apoiar nada, só pagar un pouco de diñeiro, crear a túa aplicación e mesmo realizar probas de instrumentación.

Consello # 7: nun equipo grande, as solucións internas son máis rendibles.

Pero tarde ou cedo, a medida que o equipo creza, as solucións internas serán máis rendibles. Hai un problema con estas decisións. Existe unha lei de rendementos decrecentes en economía: en calquera proxecto, cada mellora posterior é cada vez máis difícil e require cada vez máis investimento.

A economía describe toda a nosa vida, incluída a Integración Continua. Elaborei un calendario de custos laborais para cada etapa de desenvolvemento da nosa Integración Continua.

Está claro que calquera mellora é cada vez máis difícil. Mirando este gráfico, podes entender que a Integración Continua debe desenvolverse de acordo co crecemento do tamaño do equipo. Para un equipo de dúas persoas, pasar 50 días desenvolvendo unha granxa interna de emuladores é unha idea mediocre. Pero ao mesmo tempo, para un equipo grande, non facer Integración Continua en absoluto tamén é unha mala idea, porque problemas de integración, arranxar comunicación, etc. levará aínda máis tempo.

Comezamos coa idea de que a automatización é necesaria porque a xente é cara, comete erros e é preguiceiro. Pero a xente tamén automatiza. Polo tanto, todos os mesmos problemas aplícanse á automatización.

• A automatización é cara. Lembra o horario laboral.
• Cando se trata de automatización, a xente comete erros.
• Ás veces é moi preguiceiro automatizar, porque todo funciona así. Por que mellorar outra cousa, por que toda esta Integración Continua?

Pero teño estatísticas: os erros cóllense no 20% das montaxes. E isto non é porque os nosos desenvolvedores escriban mal o código. Isto débese a que os desenvolvedores confían en que, se cometen algún erro, non acabará no desenvolvemento, senón que será capturado por verificacións automatizadas. En consecuencia, os desenvolvedores poden dedicar máis tempo a escribir código e cousas interesantes, en lugar de executar e probar algo localmente.

Practica a Integración Continua. Pero con moderación.

Por certo, Nikolai Nesterov non só fai excelentes informes, senón que tamén é membro do comité do programa. AppsConf e axuda a outros a preparar discursos significativos para ti. A integridade e utilidade do programa da próxima conferencia pode ser avaliada por temas en horario. E para obter máis información, achégate a Infospace do 22 ao 23 de abril.

Fonte: www.habr.com