O informe falará sobre algunhas prácticas de DevOps, pero desde o punto de vista dun programador. Normalmente, todos os enxeñeiros que se unen a DevOps xa teñen varios anos de experiencia administrativa. Pero isto non significa que aquí non haxa lugar para o desenvolvedor. Na maioría das veces, os desenvolvedores están ocupados resolvendo "o seguinte erro crítico urxente do día" e non teñen tempo nin para botar unha ollada rápida ao campo DevOps. Segundo entende o autor, DevOps é, en primeiro lugar, sentido común. En segundo lugar, é unha oportunidade para ser máis efectivos. Se es un programador, tes sentido común e queres ser máis eficaz como xogador de equipo, este informe é para ti.
Déixame presentarme, recoñezo plenamente que hai xente na sala que non me coñece. Chámome Anton Boyko, son un MVP de Microsoft Azure. Que é MVP? Este é Model-View-Presenter. Model-View-Presenter son exactamente eu.
Ademais, actualmente ocupo o cargo de arquitecto de solucións en Ciklum. E hai pouco merqueime un dominio tan fermoso e actualicei o meu correo electrónico, que adoito mostrar nas presentacións. Podes escribirme a: me [dog] byokoant.pro. Podes enviarme un correo electrónico con preguntas. Eu adoito responderlles. O único é que non me gustaría recibir preguntas por correo electrónico relacionadas con dous temas: política e relixión. Podes escribirme sobre todo o demais por correo electrónico. Pasará algún tempo, responderei.
Algunhas palabras sobre ti:
- Levo 10 anos neste campo.
- Traballei en Microsoft.
- Son o pai fundador da comunidade Azure ucraína, que fundamos nalgún lugar en 2014. E aínda o temos e estamos a desenvolver.
- Tamén son o pai do fundador da conferencia Azure, que acollemos en Ucraína.
- Tamén axudo a organizar o Global Azure Bootcamp en Kiev.
- Como dixen, son un MVP de Microsoft Azure.
- Falo en conferencias con bastante frecuencia. Encántame moito falar nas conferencias. Durante o ano pasado puiden actuar unhas 40 veces. Se pasas por Ucraína, Bielorrusia, Polonia, Bulgaria, Suecia, Dinamarca, Países Baixos, España ou dás ou tomas outro país de Europa, entón é moi posible que cando vaias a unha conferencia que teña un tema de nube no seu fluxo, podes verme na lista de falantes.
- Tamén son fan de Star Trek.
Falemos un pouco da Axenda. A nosa axenda é moi sinxela:
- Falaremos do que é DevOps. Imos falar por que isto é importante. Anteriormente, DevOps era unha palabra clave que escribiu no seu currículo e inmediatamente recibiu + $ 500 en salario. Agora tes que escribir, por exemplo, blockchain no teu currículo para obter + 500 dólares ao teu salario.
- E despois, cando entendamos un pouco o que é isto, falaremos sobre cales son as prácticas de DevOps. Pero non tanto no contexto de DevOps en xeral, senón sobre aquelas prácticas de DevOps que poden ser de interese para os desenvolvedores. Vouche dicir por que poden ser do teu interese. Vouche dicir por que deberías facer isto e como pode axudarche a experimentar menos dor.
Unha imaxe tradicional que mostra moita xente. Isto é o que ocorre en moitos proxectos. Isto é cando temos departamentos de desenvolvemento e operacións que admiten o noso software. E estes departamentos non se comunican entre si.
Quizais, se non fose capaz de sentilo tan claramente nos departamentos de DevOps e operacións, poida facer unha analoxía cos departamentos de Dev e QA. Hai xente que desenvolve software e hai persoas de control de calidade que son malas desde o punto de vista dos desenvolvedores. Por exemplo, envio o meu marabilloso código ao repositorio e hai algún canalla alí sentado que me devolve este código e di que o teu código é malo.
Todo isto ocorre porque as persoas non se comunican entre elas. E lánzanse uns paquetes, algunha aplicación entre si por algún muro de malentendidos e intentan facer algo con eles.
É precisamente este muro que a cultura DevOps está deseñada para destruír, é dicir. obrigar ás persoas a comunicarse entre elas e, polo menos, comprender o que fan as diferentes persoas do proxecto e por que é importante o seu traballo.
E cando falamos de DevOps, alguén che dirá que DevOps é cando o proxecto ten unha integración continua; alguén dirá que DevOps é se o proxecto implementa a práctica "infraestrutura como código"; alguén dirá que o primeiro paso para DevOps é a ramificación de funcións, as bandeiras de funcións.
Esencialmente, todo isto é certo ao seu xeito. Pero estas son só as prácticas definitivas que temos. Antes de pasar a estas prácticas, suxiro mirar esta diapositiva, que mostra as 3 etapas da implementación da metodoloxía Dev-Ops no teu proxecto, na túa empresa.
Esta diapositiva tamén ten un segundo nome non oficial. Podes buscar en liña para descubrir cales son os 3 Mosqueteiros de DevOps. É posible que atopes este artigo. Por que 3 Mosqueteiros? Abaixo di: persoas, procesos e produtos, é dicir. PPP - Porthos, Porthos e Porthos. Aquí están os 3 mosqueteiros de DevOps. Este artigo describe con máis detalle por que isto é importante e o que implica.
Cando comeza a implementar unha cultura DevOps, é moi importante que se implemente na seguinte orde.
Inicialmente cómpre falar coa xente. E cómpre explicarlle á xente o que é e como poden obter algúns beneficios del.
A nosa conferencia chámase DotNet Fest. E como me dixeron os organizadores, invitamos principalmente a un público de desenvolvedores aquí, polo que espero que a maioría da xente do salón estea implicada no desenvolvemento.
Falaremos da xente, falaremos do que queren facer os desenvolvedores todos os días. Que é o que máis queren? Queren escribir algún código novo, usar marcos novos, crear novas funcións. Que é o que menos queren os desenvolvedores? Corrixir erros antigos. Espero que esteas de acordo comigo. Isto é o que queren os desenvolvedores. Queren escribir novas funcións, non queren corrixir erros.
O número de erros que produce un programador en particular depende do recto que estean os seus brazos e de canto medran dos seus ombreiros, e non dos seus petos traseiros. Pero, con todo, cando temos un proxecto grande, ás veces ocorre que é imposible facer un seguimento de todo, polo que estaría ben que utilizamos algúns enfoques que nos axuden a escribir un código máis estable e de maior calidade.
Que é o que máis queren os QA? Non sei se están no corredor. É difícil para min dicir que quero un control de calidade, porque nunca o fun. E sen ofender aos rapaces, dirase que espero non o faga nunca. Pero non polo que considero o seu traballo sen sentido e inútil, senón porque non me considero unha persoa que puidese facer este traballo de forma eficiente, polo que nin sequera intentarei facelo. Pero polo que entendo, o que máis non lle gusta ao control de calidade é ir traballar pola mañá, realizando constantemente algún tipo de probas de regresión, pisando os mesmos erros que informaron aos desenvolvedores hai 3 sprints e dicindo: “Cando vai , Monsieur D 'Artagnan, corrixa este erro.' E o señor D'Artagnan respondelle: "Si, si, si, xa o arranxei". E como ocorre que solucionei un erro e fixen 5 ao longo do camiño.
As persoas que admiten esta solución na produción queren que esta solución funcione sen erros, para que non teñan que reiniciar o servidor todos os venres, cando toda a xente normal vai ao bar. Os desenvolvedores despregados o venres, os administradores permanecen ata o sábado, intentando arranxar e arranxar esta implementación.
E cando lle explicas á xente que están dirixidas a resolver os mesmos problemas, podes pasar á formalización dos procesos. É moi importante. Por que? Porque cando dicimos "formalización", é importante que describas como ocorren os teus procesos polo menos nalgún lugar dunha servilleta. Debe entender que se, por exemplo, se implementa nun ambiente de control de calidade ou nun ambiente de produción, sempre ocorre nesta orde; nestas fases executamos, por exemplo, probas unitarias automáticas e probas de IU. Despois da implantación, comprobamos se a implantación foi ben ou mal. Pero xa tes unha lista clara de accións que hai que repetir unha e outra vez cando te implantes en produción.
E só cando se formalicen os seus procesos, comeza a seleccionar produtos que che axuden a automatizar estes procesos.
Desafortunadamente, moitas veces vexo que isto ocorre ao revés. En canto alguén escoita a palabra "DevOps", inmediatamente suxiren instalar Jenkins, porque cren que en canto instale Jenkins, terán DevOps. Instalaron a Jenkins, leron os artigos "Como" no sitio web de Jenkins, intentaron inserir procesos nestes artigos de Como facer, e logo chegaron á xente e se inclinaron, dicindo que o libro di que cómpre facelo deste xeito. así que o facemos deste xeito.
Non é que Jenkins sexa unha mala ferramenta. Non quero dicir iso de ningún xeito. Pero este é só un dos produtos. E que produto utilizas debería ser a túa última decisión, e non a primeira. O seu produto non debe ser impulsado pola implementación de cultura e enfoques. Isto é moi importante de entender, por iso paso tanto tempo nesta diapositiva e explico todo isto durante tanto tempo.
Falemos das prácticas de DevOps en xeral. Que son? Cal é a diferenza? Como probalos? Por que son importantes?
A primeira práctica da que quizais escoitou falar chámase Integración Continua. Quizais alguén do proxecto teña Integración Continua (CI).
O maior problema é que a maioría das veces cando lle pregunto a unha persoa: "Tes CI no proxecto?" e di: "Si", entón cando lle pregunto que fai, descríbeme absolutamente todo o proceso de automatización. Isto non é totalmente certo.
De feito, a práctica do CI só ten como obxectivo integrar o código que diferentes persoas escriben nunha única base de código. Iso é todo.
Xunto con CI, adoita haber outras prácticas ao longo do camiño, como a implantación continua, a xestión de versións, pero diso falaremos máis tarde.
O propio CI dinos que diferentes persoas escriben código e este código debe estar continuamente integrado nunha única base de código.
Que nos aporta isto e por que é importante? Se temos DotNet, iso é bo, é unha linguaxe compilada, podemos compilar a nosa aplicación. Se compila, isto xa é un bo sinal. Isto aínda non significa nada, pero é o primeiro bo sinal de que polo menos podemos compilar.
Despois podemos realizar algunhas probas, que tamén é unha práctica separada. As probas son todas verdes: este é o segundo bo sinal. Pero de novo, isto non significa nada.
Pero por que farías isto? Todas as prácticas das que vou falar hoxe teñen aproximadamente o mesmo valor, é dicir, aproximadamente os mesmos beneficios e tamén se miden aproximadamente do mesmo xeito.
En primeiro lugar, permítelle acelerar a entrega. Como isto lle permite acelerar a entrega? Cando facemos novos cambios na nosa base de código, podemos tentar inmediatamente facer algo con este código. Non agardamos ata que chegue o xoves porque o xoves lanzámolo a QA Environment, facémolo aquí e aquí mesmo.
Vouche contar unha historia triste da miña vida. Foi hai moito tempo, cando aínda era novo e guapo. Agora xa son novo, fermoso e intelixente, e modesto. Hai tempo estiven nun proxecto. Tiñamos un gran equipo duns 30 desenvolvedores. E tivemos un proxecto empresarial grande e grande que se desenvolveu durante uns 10 anos. E tiñamos diferentes ramas. No repositorio tiñamos unha rama na que andaban os desenvolvedores. E había unha rama que mostraba a versión do código que está en produción.
A rama de produción estaba 3 meses por detrás da rama que estaba dispoñible para os desenvolvedores. Que significa isto? Isto significa que, en canto teño un erro nalgún lugar que vai á produción por culpa dos desenvolvedores, porque o permitiron, e por culpa de QA, porque o miraron, isto significa que se recibo un tarefa para a revisión para a produción, entón teño que revertir os cambios no meu código hai 3 meses. Teño que lembrar o que tiña hai 3 meses e tentar solucionalo alí.
Se aínda non tiveches esta experiencia, podes probala no teu proxecto doméstico. O principal é que non o probes nun comercial. Escribe un par de liñas de código, esquéceas durante seis meses e despois volve e tenta explicar rapidamente de que se trata esas liñas de código e como podes corrixilas ou optimizalas. É unha experiencia moi, moi emocionante.
Se temos unha práctica de Integración Continua, isto permítenos comprobalo cunha serie de ferramentas automatizadas aquí e agora mesmo, en canto escribín o meu código. Quizais isto non me dea a imaxe completa, pero, con todo, eliminará polo menos algúns dos riscos. E se hai algún erro potencial, sabereino agora mesmo, é dicir, literalmente nun par de minutos. Non necesitarei retroceder 3 meses. Só necesitarei retroceder 2 minutos. Unha boa máquina de café nin sequera terá tempo para preparar o café en 2 minutos, así que é xenial.
Isto ten o valor de que se pode repetir unha e outra vez en cada proxecto, é dicir. non só na que o configuraches. Podes repetir tanto a práctica en si e o propio CI repetirase para cada novo cambio que fagas no proxecto. Isto permíteche optimizar os recursos porque o teu equipo traballa de forma máis eficiente. Xa non terás unha situación na que che veña un erro do código co que traballaches hai 3 meses. Xa non terás cambio de contexto cando te sentes e pases as dúas primeiras horas intentando comprender o que pasou entón e entrar na esencia do contexto antes de comezar a corrixir algo.
Como podemos medir o éxito ou o fracaso desta práctica? Se informas ao gran xefe do que implementamos no proxecto CI, escoita bla bla bla. Implementámolo, vale, pero por que, que nos aportou, como o medimos, como o estamos implementando correctamente ou incorrectamente?
O primeiro é que, grazas a CI, podemos implementar cada vez con máis frecuencia, e con máis frecuencia precisamente porque o noso código é potencialmente máis estable. Do mesmo xeito, o noso tempo para atopar un erro redúcese e o tempo para corrixir este erro precisamente porque recibimos unha resposta do sistema aquí mesmo e agora mesmo, o que está mal co noso código.
Outra práctica que temos é a práctica de probas de automatización, que a maioría das veces vén coa práctica de CI. Van da man.
Que é importante entender aquí? É importante entender que as nosas probas son diferentes. E cada proba automatizada está dirixida a resolver os seus propios problemas. Temos, por exemplo, probas unitarias que nos permiten probar un módulo por separado, é dicir. Como funciona ao baleiro? Isto é bo.
Tamén temos probas de integración que nos permiten comprender como se integran os distintos módulos entre si. Tamén é bo.
É posible que teñamos probas de automatización da IU que nos permitan comprobar o ben que o traballo coa IU cumpre determinados requisitos establecidos polo cliente, etc.
As probas específicas que realizas poden afectar a frecuencia coa que as executas. As probas unitarias adoitan escribirse breves e pequenas. E pódense lanzar regularmente.
Se falamos de probas de automatización da IU, é bo se o teu proxecto é pequeno. As probas de automatización da IU poden levar un tempo suficiente. Pero normalmente unha proba de automatización da IU é algo que leva varias horas nun proxecto grande. E é bo se son unhas horas. O único é que non ten sentido executalos para cada construción. Ten sentido executalos pola noite. E cando todos chegaron ao traballo pola mañá: tanto os probadores como os desenvolvedores, recibiron algún tipo de informe de que realizamos a proba automática da IU pola noite e obtivemos estes resultados. E aquí, unha hora de traballo dun servidor que comprobará que o teu produto cumpre uns requisitos será moito máis barato que unha hora de traballo do mesmo enxeñeiro de control de calidade, aínda que sexa un enxeñeiro de control de calidade junior que traballe para comer e agradecer. De todos os xeitos, unha hora de funcionamento da máquina será máis barata. É por iso que ten sentido investir nel.
Teño outro proxecto no que estiven traballando. Tivemos sprints de dúas semanas neste proxecto. O proxecto era grande, importante para o sector financeiro, e non se puido cometer un erro. E despois dun sprint de dúas semanas, o ciclo de desenvolvemento foi seguido por un proceso de proba, que levou outras 4 semanas. Tenta imaxinar a magnitude da traxedia. Escribimos código durante dúas semanas, despois facémolo como CodeFreeze, empaquetámolo nunha nova versión da aplicación e lanzámolo aos probadores. Os probadores probano durante outras 4 semanas, é dicir. Mentres o están a probar, temos tempo para prepararlles dúas versións máis. Este é un caso realmente triste.
E dixémoslles que, se queres ser máis produtivo, ten sentido que implementes prácticas de proba automatizada, porque isto é o que che doe aquí mesmo, agora mesmo.
Practicar a implantación continua. Xenial, acabaches de construír. Isto xa é bo. Compilouse o teu código. Agora sería bo implementar esta compilación nalgún ambiente. Digamos nun ambiente para desenvolvedores.
Por que é importante? En primeiro lugar, podes ver o éxito que tes co propio proceso de implantación. Coñecín proxectos coma este, cando pregunto: “Como implementas unha nova versión da aplicación?”, os mozos dinme: “Montámolo e empaquetámolo nun arquivo zip. Enviámosllo ao administrador por correo. O administrador descarga e amplía este arquivo. E toda a oficina comeza a rezar para que o servidor recolla a nova versión.
Imos comezar con algo sinxelo. Por exemplo, esqueceron poñer CSS no arquivo ou esqueceron cambiar o hashtag no nome do ficheiro java-script. E cando facemos unha solicitude ao servidor, o navegador pensa que xa ten este ficheiro java-script e decide non descargalo. E había unha versión antiga, faltaba algo. En xeral, pode haber moitos problemas. Polo tanto, a práctica da Implementación Continua permítelle, polo menos, probar o que pasaría se tomase unha imaxe de referencia limpa e a cargase nun ambiente completamente limpo. Podes ver a onde leva isto.
Ademais, cando integras código entre si, é dicir. entre o comando, isto permítelle ver tamén como se ve na IU.
Un dos problemas que se producen cando se usa moito java-script de vainilla é que dous desenvolvedores declararon precipitadamente unha variable co mesmo nome no obxecto xanela. E despois, dependendo da túa sorte. Cuxo ficheiro java-script se extrae segundo sobrescribirá os cambios do outro. Tamén é moi emocionante. Entras: unha cousa funciona para unha persoa, outra non para outra. E é "marabilloso" cando todo sae en produción.
A seguinte práctica que temos é a práctica da Restauración automática, é dicir, volver á versión anterior da aplicación.
Por que é importante para os desenvolvedores? Aínda hai quen lembra os afastados e afastados anos 90, cando os ordenadores eran grandes e os programas pequenos. E a única forma de desenvolver web era a través de PHP. Non é que PHP sexa unha mala linguaxe, aínda que o sexa.
Pero o problema era outro. Cando implementamos unha nova versión do noso sitio php, como a implementamos? A maioría das veces abrimos Far Manager ou outra cousa. E cargou estes ficheiros a FTP. E de súpeto decatámonos de que tiñamos algún pequeno erro, por exemplo, esquecemos poñer un punto e coma ou esquecemos cambiar o contrasinal da base de datos, e hai un contrasinal para a base de datos, que está no host local. E decidimos conectarnos rapidamente a FTP e editar os ficheiros alí mesmo. Isto é só lume! Isto é o que era popular nos anos 90.
Pero, se non miraches o calendario, os anos 90 foron hai case 30 anos. Agora todo está a suceder un pouco diferente. E tenta imaxinar a magnitude da traxedia cando che din: “Desplegámonos á produción, pero alí algo saíu mal. Aquí tes o teu inicio de sesión e contrasinal FTP, conéctate á produción e solucionalo rapidamente alí. Se es Chuck Norris, isto funcionará. Se non, corres o risco de que se corrixas un erro, fagas 10 máis. Por iso precisamente esta práctica de volver á versión anterior permíteche conseguir moito.
Aínda que algo malo se metese en prod nalgún lugar, entón é malo, pero non fatal. Podes volver á versión anterior que tes. Chámalle unha copia de seguridade, se é máis fácil percibilo nesa terminoloxía. Podes volver a esta versión anterior e os usuarios aínda poderán traballar co teu produto e terás un tempo de almacenamento intermedio adecuado. Podes tomar todo isto con calma, sen présa, probalo localmente, solucionalo e despois cargar unha nova versión. Realmente ten sentido facer isto.
Agora imos tentar combinar dalgún xeito as dúas prácticas anteriores xuntas. Teremos un terceiro chamado Release Management.
Cando falamos de Implementación Continua na súa forma clásica, dicimos que debemos extraer código dalgunha rama do repositorio, compilalo e despregalo. É bo que teñamos o mesmo ambiente. Se temos varios ambientes, isto significa que temos que tirar o código cada vez, incluso dende o mesmo commit. Tirarémolo cada vez, construirémolo cada vez e despregámolo a un novo entorno. En primeiro lugar, este é o momento, porque para construír un proxecto, se tes un grande e veu dos anos 90, pode levar varias horas.
Ademais, hai outra tristeza. Cando creas, incluso na mesma máquina, construirás as mesmas fontes, aínda non tes garantía de que esta máquina estea no mesmo estado que estaba durante a última compilación.
Digamos que alguén entrou e actualizou DotNet para ti ou, pola contra, alguén decidiu eliminar algo. E entón tes unha disonancia cognitiva que a partir deste compromiso hai dúas semanas estabamos construíndo unha compilación e todo estaba ben, pero agora parece a mesma máquina, a mesma confirmación, o mesmo código que estamos tentando construír, pero non funciona. . Estarás lidando con isto durante moito tempo e non é un feito que o descubrirás. Cando menos, estragarás moito os nervios.
Polo tanto, a práctica de Release Management suxire introducir unha abstracción adicional chamada repositorio de artefactos ou galería ou biblioteca. Podes chamalo como queiras.
A idea principal é que, en canto teñamos algún tipo de commit alí, por exemplo, nunha sucursal que esteamos preparados para implantar nos nosos diferentes contornos, recompilamos aplicacións deste commit e todo o que necesitamos para esta aplicación, empaquetámolo. nun arquivo zip e gárdao nun almacenamento fiable. E desde este almacenamento podemos obter este arquivo zip en calquera momento.
Despois collemos e despregámolo automaticamente no ambiente de desenvolvemento. Corremos alí e, se todo está ben, desprazámonos ao escenario. Se todo está ben, entón implementamos o mesmo arquivo na produción, os mesmos binarios, compilados exactamente unha vez.
Ademais, cando temos unha galería como esta, tamén nos axuda a abordar os riscos que abordamos na última diapositiva cando falamos de retroceder á versión anterior. Se despregaches algo mal por accidente, sempre podes coller calquera outra versión anterior desta galería e anulala a estes ambientes do mesmo xeito. Isto permítelle volver facilmente á versión anterior se algo sae mal.
Hai outra gran práctica. Ti e mais eu entendemos que cando recuperamos as nosas aplicacións a unha versión anterior, isto pode significar que tamén necesitamos a infraestrutura da versión anterior.
Cando falamos de infraestrutura virtual, moita xente pensa que isto é algo que configuran os administradores. E se necesitas, por exemplo, obter un novo servidor no que queres probar unha nova versión da túa aplicación, debes escribir un ticket para os administradores ou devops. Os devops tardarán 3 semanas para iso. E despois de 3 semanas diránche que instalamos unha máquina virtual para ti, cun núcleo, dous gigabytes de RAM e un servidor Windows sen DotNet. Vostede di: "Pero eu quería DotNet". Eles: "Ok, volve en 3 semanas".
A idea é que ao usar a Infraestrutura como prácticas de Código, pode tratar a súa infraestrutura virtual como un recurso máis.
Quizais, se algún de vós está a desenvolver aplicacións en DotNet, quizais escoitou falar dunha biblioteca chamada Entity Framework. E quizais xa escoitaches que Entity Framework é un dos enfoques que Microsoft está a impulsar activamente. Para traballar cunha base de datos, este é un enfoque chamado Code First. Isto é cando describe en código como quere que se vexa a súa base de datos. E despois implementa a aplicación. Conéctase á base de datos, el mesmo determina que táboas hai e cales non, e crea todo o que necesitas.
Podes facer o mesmo coa túa infraestrutura. Non hai diferenza entre se precisa unha base de datos para un proxecto ou se necesita un servidor Windows para un proxecto. É só un recurso. E pode automatizar a creación deste recurso, pode automatizar a configuración deste recurso. En consecuencia, cada vez que queiras probar algún novo concepto, algún novo enfoque, non terás que escribir un ticket para devops, simplemente podes implementar unha infraestrutura illada por ti mesmo a partir de modelos preparados, de scripts preparados e implementala. alí todos os teus experimentos. Podes eliminar isto, obter algúns resultados e informar máis sobre iso.
A seguinte práctica, que tamén existe e tamén é importante, pero que poucas persoas usan, é o seguimento do rendemento das aplicacións.
Só quería dicir unha cousa sobre o seguimento do rendemento das aplicacións. Que é o máis importante desta práctica? Isto é o que é o mesmo que o seguimento do rendemento da aplicación que reparar un apartamento. Este non é un estado final, é un proceso. Debe facelo regularmente.
En boa forma, sería bo levar a cabo o seguimento do rendemento da aplicación en case todas as compilacións, aínda que, como entendes, isto non sempre é posible. Pero, como mínimo, debe realizarse para cada lanzamento.
Por que é importante? Porque se de súpeto experimentas unha caída no rendemento, entón tes que entender claramente por que. Se o teu equipo ten, por exemplo, sprints de dúas semanas, polo menos unha vez cada dúas semanas deberías implementar a túa aplicación nalgún servidor separado, onde teñas un procesador, memoria RAM, discos, etc. claramente fixados. E executa as mesmas probas de rendemento. . Obtén o resultado. Mira como cambiou con respecto ao sprint anterior.
E se descobres que a baixada baixou moito nalgún lugar, significará que foi só polos cambios que tiveron lugar nas últimas dúas semanas. Isto permitirache identificar e solucionar o problema moito máis rápido. E de novo, estas son aproximadamente as mesmas métricas polas que podes medir o éxito que o fixeches.
A seguinte práctica que temos é a práctica de Xestión da Configuración. Son moi poucos os que se toman isto en serio. Pero créame, isto é realmente unha cousa moi seria.
Hai pouco houbo unha historia divertida. Os mozos achegáronse a min e dixéronme: "Axúdanos a realizar unha auditoría de seguridade da nosa aplicación". Miramos o código xuntos durante moito tempo, faláronme da aplicación, debuxaron diagramas. E máis ou menos todo era lóxico, comprensible, seguro, pero había un PERO! Tiñan ficheiros de configuración no seu control de fontes, incluídos os de produción coa base de datos IP, con inicios de sesión e contrasinais para conectarse a estas bases de datos, etc.
E dígolle: "Rapaces, está ben, pechaches o teu ambiente de produción cun firewall, pero o feito de que teñas o inicio de sesión e o contrasinal da base de datos de produción directamente no control de orixe e que calquera desenvolvedor poida lelo xa supón un enorme risco de seguridade. . E por moi segura que sexa a túa aplicación desde o punto de vista do código, se a deixas no control de fontes, nunca aprobarás ningunha auditoría por ningún lado". Diso falo.
Xestión da configuración. Podemos ter diferentes configuracións en diferentes ambientes. Por exemplo, podemos ter diferentes inicios de sesión e contrasinais para bases de datos para control de calidade, demostración, ambiente de produción, etc.
Esta configuración tamén se pode automatizar. Sempre debe estar separado da propia aplicación. Por que? Dado que creaches a aplicación unha vez e, a continuación, a aplicación non lle importa se te conectas ao servidor SQL a través de tal IP ou tal IP, debería funcionar igual. Polo tanto, se de súpeto un de vós aínda está codificando a cadea de conexión no código, lembra que te atoparei e te castigarei se te atopas no mesmo proxecto comigo. Isto sempre se coloca nunha configuración separada, por exemplo, en web.config.
E esta configuración xa se xestiona por separado, é dicir, este é exactamente o momento no que un programador e un administrador poden vir sentarse na mesma sala. E o programador pode dicir: "Mira, aquí están os binarios da miña aplicación. Eles traballan. A aplicación necesita unha base de datos para funcionar. Aquí xunto aos binarios hai un ficheiro. Neste ficheiro, este campo é responsable do inicio de sesión, isto é para o contrasinal, isto é para a IP. Implícalo en calquera lugar". E é sinxelo e claro para o administrador. Pode implementalo en calquera lugar xestionando esta configuración.
E a última práctica da que me gustaría falar é unha práctica moi, moi relacionada coas nubes. E trae o máximo efecto se traballas na nube. Esta é a eliminación automática do teu ambiente.
Sei que nesta conferencia hai varias persoas dos equipos cos que traballo. E con todos os equipos cos que traballo, utilizamos esta práctica.
Por que? Por suposto, sería xenial que cada desenvolvedor tivese unha máquina virtual que funcione 24 horas ao día. Pero quizais isto sexa unha noticia para ti, quizais non fixeches atención, pero o propio desenvolvedor non traballa 7 horas ao día. Un programador adoita traballar 24 horas ao día. Aínda que chega cedo ao traballo, ten un gran xantar durante o cal vai ao ximnasio. Que sexan 7 horas ao día cando o programador utilice estes recursos. Segundo a nosa lexislación, temos 8 de cada 12 días nunha semana que se consideran laborables.
En consecuencia, os días laborables esta máquina non debería funcionar 24 horas, senón só 12, e os fins de semana esta máquina non debería funcionar en absoluto. Parece que todo é moi sinxelo, pero que é importante dicir aquí? Ao implementar esta sinxela práctica nesta programación básica, permíteche reducir o custo de mantemento destes ambientes nun 70 %, é dicir, colleches o prezo do teu desenvolvemento, control de calidade, demostración, ambiente e dividiuno por 3.
A pregunta é, que facer co resto do diñeiro? Por exemplo, os desenvolvedores deberían comprar ReSharper se aínda non o fixeron. Ou facer un cóctel. Se antes tiñas un ambiente no que pasaban tanto dev como QA, e xa está, agora podes facer 3 diferentes que quedarán illados e as persoas non interferirán entre si.
Respecto da diapositiva con medición continua do rendemento, como podemos comparar o rendemento se tivésemos 1 rexistros na base de datos do proxecto, dous meses despois hai un millón? Como entender por que e para que serve medir o rendemento?
Esta é unha boa pregunta, porque sempre debes medir o rendemento cos mesmos recursos. É dicir, lanzas código novo, mides o rendemento do novo código. Por exemplo, cómpre probar diferentes escenarios de rendemento, digamos que quere probar como funciona a aplicación cunha carga lixeira, onde hai 1 usuarios e o tamaño da base de datos é de 000 gigabytes. Mediches e obtiveches os números. A continuación tomamos outro escenario. Por exemplo, 5 usuarios, tamaño da base de datos 5 terabyte. Recibimos os resultados e recordámolos.
Que é importante aquí? O importante aquí é que, dependendo do escenario, do volume de datos, do número de usuarios simultáneos, etc., podes atoparte con certos límites. Por exemplo, ata o límite dunha tarxeta de rede, ou ata o límite dun disco duro, ou ata o límite das capacidades do procesador. Isto é o que é importante para entender. En diferentes escenarios atópase con certos límites. E cómpre comprender os números cando os bates.
Estamos a falar de medir o rendemento nun ambiente de proba especial? É dicir, isto non é produción?
Si, isto non é produción, é un ambiente de proba, que sempre é o mesmo para poder comparalo coas medicións anteriores.
Entendido grazas!
Se non hai preguntas, creo que podemos rematar. Grazas!
Fonte: www.habr.com