El informe hablará sobre algunas prácticas de DevOps, pero desde el punto de vista de un desarrollador. Normalmente, todos los ingenieros que se unen a DevOps ya tienen varios años de experiencia administrativa en su haber. Pero esto no significa que aquí no haya lugar para el desarrollador. La mayoría de las veces, los desarrolladores están ocupados solucionando "el próximo error urgente y crítico del día" y no tienen tiempo ni siquiera para echar un vistazo rápido al campo de DevOps. En opinión del autor, DevOps es, en primer lugar, sentido común. En segundo lugar, es una oportunidad para ser más eficaces. Si es desarrollador, tiene sentido común y quiere ser más eficaz trabajando en equipo, este informe es para usted.
Permítanme presentarme, admito plenamente que hay personas en la sala que no me conocen. Mi nombre es Anton Boyko, soy MVP de Microsoft Azure. ¿Qué es MVP? Este es Modelo-Vista-Presentador. Model-View-Presenter soy exactamente yo.
Además, actualmente ocupo el puesto de arquitecto de soluciones en Ciklum. Y recientemente me compré un dominio tan hermoso y actualicé mi correo electrónico, que suelo mostrar en las presentaciones. Puedes escribirme a: yo [perro] byokoant.pro. Puedes enviarme un correo electrónico con preguntas. Normalmente les respondo. Lo único es que no me gustaría recibir preguntas por correo electrónico relacionadas con dos temas: política y religión. Puedes escribirme sobre todo lo demás por correo electrónico. Pasará algún tiempo, responderé.
Unas pocas palabras acerca de ti:
- Llevo 10 años en este campo.
- Trabajé en Microsoft.
- Soy el padre fundador de la comunidad ucraniana Azure, que fundamos en 2014. Y todavía lo tenemos y lo estamos desarrollando.
- También soy el padre del fundador de la conferencia Azure, que organizamos en Ucrania.
- También ayudo a organizar el Global Azure Bootcamp en Kiev.
- Como dije, soy un MVP de Microsoft Azure.
- Hablo en conferencias con bastante frecuencia. Realmente me encanta hablar en conferencias. Durante el año pasado pude actuar unas 40 veces. Si pasa por Ucrania, Bielorrusia, Polonia, Bulgaria, Suecia, Dinamarca, los Países Bajos, España o, más o menos, otro país de Europa, es muy posible que cuando asista a una conferencia que tenga un tema de nube en su transmisión, es posible que me vean en la lista de oradores.
- También soy fanático de Star Trek.
Hablemos un poco de Agenda. Nuestra Agenda es muy sencilla:
- Hablaremos de qué es DevOps. Hablemos de por qué esto es importante. Anteriormente, DevOps era una palabra clave que escribías en tu currículum y recibías inmediatamente +$500 de salario. Ahora necesita escribir, por ejemplo, blockchain en su currículum para obtener +500 dólares en su salario.
- Y luego, cuando entendamos un poco qué es esto, hablaremos de qué son las prácticas DevOps. Pero no tanto en el contexto de DevOps en general, sino de aquellas prácticas de DevOps que podrían ser de interés para los desarrolladores. Te diré por qué podrían ser de tu interés. Te diré por qué deberías hacer esto y cómo puede ayudarte a experimentar menos dolor.
Una imagen tradicional que mucha gente muestra. Esto es lo que sucede en muchos proyectos. Es entonces cuando contamos con departamentos de desarrollo y operaciones que respaldan nuestro software. Y estos departamentos no se comunican entre sí.
Quizás, si no pudo sentirlo tan claramente en los departamentos de operaciones y DevOps, pueda hacer una analogía con los departamentos de desarrollo y control de calidad. Hay personas que desarrollan software y hay personas de control de calidad que son malas desde el punto de vista de los desarrolladores. Por ejemplo, envío mi maravilloso código al repositorio y hay un sinvergüenza sentado allí que me devuelve este código y dice que su código es incorrecto.
Todo esto sucede porque las personas no se comunican entre sí. Y se lanzan algunos paquetes, alguna solicitud entre sí a través de algún muro de malentendidos e intentan hacer algo con ellos.
Es precisamente este muro el que la cultura DevOps está diseñada para destruir, es decir, Obligar a las personas a comunicarse entre sí y al menos comprender qué hacen las diferentes personas en el proyecto y por qué su trabajo es importante.
Y cuando hablamos de DevOps, alguien te dirá que DevOps es cuando el proyecto tiene integración continua; alguien dirá que DevOps lo es si el proyecto implementa la práctica de “infraestructura como código”; Alguien dirá que el primer paso para DevOps es la ramificación de funciones y los indicadores de funciones.
Básicamente, todo esto es cierto a su manera. Pero estas son sólo las prácticas fundamentales que tenemos. Antes de pasar a estas prácticas, te sugiero mirar esta diapositiva, que muestra las 3 etapas de implementación de la metodología Dev-Ops en tu proyecto, en tu empresa.
Esta diapositiva también tiene un segundo nombre no oficial. Puedes buscar en línea para saber cuáles son los 3 mosqueteros de DevOps. Es posible que encuentres este artículo. ¿Por qué 3 mosqueteros? Debajo dice: personas, procesos y productos, es decir. APP – Porthos, Porthos y Porthos. Aquí están los 3 mosqueteros de DevOps. Este artículo describe con más detalle por qué esto es importante y qué implica.
Cuando comienzas a implementar una cultura DevOps, es muy importante que se implemente en el siguiente orden.
Inicialmente necesitas hablar con la gente. Y es necesario explicarle a la gente qué es y cómo pueden obtener algunos beneficios de él.
Nuestra conferencia se llama DotNet Fest. Y como me dijeron los organizadores, invitamos principalmente a una audiencia de desarrolladores, así que espero que la mayoría de las personas en la sala estén involucradas en el desarrollo.
Hablaremos de personas, hablaremos de lo que los desarrolladores quieren hacer todos los días. ¿Qué es lo que más quieren? Quieren escribir código nuevo, utilizar marcos novedosos y crear nuevas funciones. ¿Qué es lo que menos quieren los desarrolladores? Corregir errores antiguos. Espero que estés de acuerdo conmigo. Esto es lo que quieren los desarrolladores. Quieren escribir nuevas funciones, no quieren corregir errores.
La cantidad de errores que produce un desarrollador en particular depende de qué tan rectos estén sus brazos y cuánto crezcan desde sus hombros, y no desde sus bolsillos. Sin embargo, cuando tenemos un proyecto grande, a veces sucede que es imposible realizar un seguimiento de todo, por lo que sería bueno que utilicemos algunos enfoques que nos ayuden a escribir código más estable y de mayor calidad.
¿Qué es lo que más quieren los controles de calidad? No sé si están en el pasillo. Es difícil para mí decir que quiero un control de calidad, porque nunca lo he sido. Y sin ofender a los muchachos, se dirá que espero no hacerlo nunca. Pero no porque considere su trabajo sin sentido e inútil, sino porque no me considero una persona que pueda hacer este trabajo de manera eficiente, por lo que ni siquiera intentaré hacerlo. Pero por lo que tengo entendido, lo que más no le gusta al control de calidad es trabajar por la mañana, ejecutar constantemente algún tipo de prueba de regresión, encontrar los mismos errores que informaron a los desarrolladores hace 3 sprints y decir: "¿Cuándo , Monsieur D 'Artagnan, solucione este error.' Y Monsieur D'Artagnan le responde: “Sí, sí, sí, ya lo he arreglado”. ¿Y cómo sucede que arreglé un error e hice 5 en el camino?
Las personas que apoyan esta solución en producción quieren que funcione sin errores, para no tener que reiniciar el servidor todos los viernes, cuando toda la gente normal va al bar. Los desarrolladores implementaron el viernes, los administradores se sientan hasta el sábado, tratando de arreglar y arreglar esta implementación.
Y cuando le explicas a la gente que su objetivo es resolver los mismos problemas, puedes pasar a formalizar los procesos. Es muy importante. ¿Por qué? Porque cuando decimos "formalización", es importante que describas cómo ocurren tus procesos al menos en algún lugar de una servilleta. Debe comprender que si, por ejemplo, implementa en un entorno de control de calidad o en un entorno de producción, siempre sucede en este orden; en estas etapas ejecutamos, por ejemplo, pruebas unitarias automáticas y pruebas de UI. Después de la implementación, verificamos si la implementación fue bien o mal. Pero ya tiene una lista clara de acciones que deben repetirse una y otra vez cuando implementa en producción.
Y solo cuando sus procesos estén formalizados, comenzará a seleccionar productos que lo ayudarán a automatizar estos procesos.
Desafortunadamente, muy a menudo veo que esto sucede al revés. Tan pronto como alguien escucha la palabra "DevOps", inmediatamente sugiere instalar Jenkins, porque cree que tan pronto como instale Jenkins, tendrá DevOps. Instalaron Jenkins, leyeron los artículos "Cómo hacer" en el sitio web de Jenkins, intentaron incluir procesos en estos artículos Cómo hacerlo, y luego se acercaron a la gente y la inclinaron, diciendo que el libro dice que hay que hacerlo de esta manera. entonces lo hacemos de esta manera.
No es que Jenkins sea una mala herramienta. No quiero decir eso de ninguna manera. Pero este es sólo uno de los productos. Y el producto que utilice debe ser su última decisión, y de ninguna manera la primera. Su producto no debe estar impulsado por la implementación de cultura y enfoques. Es muy importante entender esto, y es por eso que dedico tanto tiempo a esta diapositiva y explico todo esto durante tanto tiempo.
Hablemos de las prácticas de DevOps en general. ¿Qué son? ¿Cuál es la diferencia? ¿Cómo probárselos? ¿Por qué son importantes?
La primera práctica de la que quizás haya oído hablar se llama Integración Continua. Quizás alguien en el proyecto tenga Integración Continua (CI).
El mayor problema es que, con mayor frecuencia, cuando le pregunto a una persona: "¿Tiene CI en el proyecto?" y dice: “Sí”, luego cuando le pregunto qué hace, me describe absolutamente todo el proceso de automatización. Esto no es enteramente verdad.
De hecho, la práctica de la CI tiene como único objetivo integrar el código que escriben diferentes personas en una especie de código base único. Eso es todo.
Junto con la CI, normalmente existen otras prácticas en el camino, como la implementación continua y la gestión de versiones, pero hablaremos de eso más adelante.
La propia CI nos dice que diferentes personas escriben código y este código debe integrarse continuamente en una única base de código.
¿Qué nos aporta esto y por qué es importante? Si tenemos DotNet, entonces está bien, es un lenguaje compilado, podemos compilar nuestra aplicación. Si se compila, ya es una buena señal. Esto no significa nada todavía, pero es la primera buena señal de que al menos podemos compilar.
Luego podemos realizar algunas pruebas, que también es una práctica aparte. Todas las pruebas están en verde: esta es la segunda buena señal. Pero repito, esto no significa nada.
¿Pero por qué harías esto? Todas las prácticas de las que hablaré hoy tienen aproximadamente el mismo valor, es decir, aproximadamente los mismos beneficios y también se miden aproximadamente de la misma manera.
En primer lugar, le permite acelerar la entrega. ¿Cómo le permite esto acelerar la entrega? Cuando realizamos algunos cambios nuevos en nuestra base de código, inmediatamente podemos intentar hacer algo con este código. No esperamos hasta que llegue el jueves porque el jueves lo publicamos en QA Environment, lo hacemos aquí y aquí.
Te contaré una triste historia de mi vida. Fue hace mucho tiempo, cuando todavía era joven y guapo. Ahora ya soy joven, hermosa, inteligente y modesta. Hace algún tiempo estuve en un proyecto. Teníamos un gran equipo de unos 30 desarrolladores. Y teníamos un gran proyecto empresarial que se desarrolló durante unos 10 años. Y teníamos diferentes ramas. En el repositorio teníamos una rama por la que caminaban los desarrolladores. Y había una rama que mostraba la versión del código que está en producción.
La rama de producción estaba 3 meses por detrás de la rama que estaba disponible para los desarrolladores. ¿Qué quiere decir esto? Esto significa que tan pronto como tengo un error en algún lugar que va a producción por culpa de los desarrolladores, porque lo permitieron, y por culpa de QA, porque lo miraron, entonces esto significa que si recibo un tarea de revisión para producción, luego tengo que revertir los cambios de mi código de hace 3 meses. Tengo que recordar lo que tuve hace 3 meses y tratar de arreglarlo ahí.
Si aún no has tenido esta experiencia, puedes probarla en el proyecto de tu hogar. Lo principal es que no lo pruebes en uno comercial. Escriba un par de líneas de código, olvídese de ellas durante seis meses y luego regrese e intente explicar rápidamente de qué se tratan esas líneas de código y cómo puede solucionarlas u optimizarlas. Es una experiencia muy, muy emocionante.
Si tenemos una práctica de Integración Continua, esto nos permite verificarla con una serie de herramientas automatizadas aquí y ahora, tan pronto como haya escrito mi código. Puede que esto no me dé una visión completa, pero aun así eliminará al menos algunos de los riesgos. Y si hay algún error potencial, lo sabré ahora mismo, es decir, literalmente en un par de minutos. No necesitaré retroceder 3 meses. Sólo necesitaré retroceder 2 minutos. Una buena máquina de café ni siquiera tendrá tiempo de preparar café en 2 minutos, así que eso es genial.
Esto tiene el valor de que se puede repetir una y otra vez en cada proyecto, es decir. no sólo en el que lo configuraste. Puede repetir tanto la práctica en sí como el CI en sí se repetirá para cada nuevo cambio que realice en el proyecto. Esto te permite optimizar recursos porque tu equipo trabaja de manera más eficiente. Ya no tendrá una situación en la que le llegue un error del código con el que trabajó hace 3 meses. Ya no tendrás cambios de contexto cuando te sientes y pases las primeras dos horas tratando de comprender lo que sucedió en ese momento y llegar a la esencia del contexto antes de comenzar a corregir algo.
¿Cómo podemos medir el éxito o el fracaso de esta práctica? Si le informa al gran jefe lo que implementamos en el proyecto de CI, oirá bla, bla, bla. Lo implementamos, vale, pero ¿por qué, qué nos aportó, cómo lo medimos, qué tan correcta o incorrectamente lo estamos implementando?
La primera es que, gracias a la CI, podemos implementar cada vez con más frecuencia, y con mayor frecuencia precisamente porque nuestro código es potencialmente más estable. De la misma manera, nuestro tiempo para encontrar un error se reduce y el tiempo para corregir este error se reduce precisamente porque recibimos una respuesta del sistema aquí y ahora, de lo que está mal en nuestro código.
Otra práctica que tenemos es la práctica de pruebas de automatización, que suele venir junto con la práctica de CI. Van de la mano.
¿Qué es importante entender aquí? Es importante entender que nuestras pruebas son diferentes. Y cada prueba automatizada tiene como objetivo resolver sus propios problemas. Tenemos, por ejemplo, pruebas unitarias que nos permiten probar un módulo por separado, es decir. ¿Cómo funciona en el vacío? Esto es bueno.
También contamos con pruebas de integración que nos permiten entender cómo se integran los diferentes módulos entre sí. También es bueno.
Es posible que tengamos pruebas de automatización de UI que nos permitan comprobar qué tan bien el trabajo con la UI cumple con ciertos requisitos marcados por el cliente, etc.
Las pruebas específicas que ejecute pueden afectar la frecuencia con la que las ejecuta. Las pruebas unitarias suelen estar escritas de forma breve y pequeña. Y se pueden lanzar periódicamente.
Si hablamos de pruebas de automatización de UI, entonces es bueno si tu proyecto es pequeño. Las pruebas de automatización de la interfaz de usuario pueden llevar un tiempo adecuado. Pero, por lo general, una prueba de automatización de la interfaz de usuario es algo que lleva varias horas en un proyecto grande. Y es bueno si son unas horas. Lo único es que no tiene sentido ejecutarlos para cada compilación. Tiene sentido ejecutarlos por la noche. Y cuando todos vinieron a trabajar por la mañana: tanto los evaluadores como los desarrolladores, recibieron algún tipo de informe de que ejecutamos la prueba automática de la interfaz de usuario por la noche y obtuvimos estos resultados. Y aquí, una hora de trabajo de un servidor que comprobará que su producto cumple con algunos requisitos será mucho más barata que una hora de trabajo del mismo ingeniero de control de calidad, incluso si es un ingeniero de control de calidad junior que trabaja para alimentos y gracias. De todos modos, una hora de funcionamiento de la máquina resultará más económica. Por eso tiene sentido invertir en él.
Tengo otro proyecto en el que he estado trabajando. Tuvimos sprints de dos semanas en este proyecto. El proyecto era grande, importante para el sector financiero y no se podía cometer un error. Y después de un sprint de dos semanas, al ciclo de desarrollo le siguió un proceso de prueba, que duró otras 4 semanas. Trate de imaginar la escala de la tragedia. Escribimos código durante dos semanas, luego lo hacemos según CodeFreeze, lo empaquetamos en una nueva versión de la aplicación y lo implementamos para los evaluadores. Los probadores lo prueban durante otras 4 semanas, es decir. Mientras lo prueban, tenemos tiempo de prepararles dos versiones más. Este es un caso realmente triste.
Y les dijimos que si quieren ser más productivos, tiene sentido que implementen prácticas de pruebas automatizadas, porque esto es lo que les duele aquí y ahora.
Practique la implementación continua. Genial, has terminado de construir. Esto ya es bueno. Su código se ha compilado. Ahora sería bueno implementar esta compilación en algún entorno. Digamos en un entorno para desarrolladores.
¿Por qué es importante? En primer lugar, puede observar el éxito que tiene con el proceso de implementación en sí. He conocido proyectos como este, cuando pregunto: “¿Cómo se implementa una nueva versión de la aplicación?”, los chicos me dicen: “La ensamblamos y la empaquetamos en un archivo zip. Se lo enviamos al administrador por correo. El administrador descarga y expande este archivo. Y toda la oficina comienza a rezar para que el servidor acepte la nueva versión”.
Comencemos con algo simple. Por ejemplo, se olvidaron de poner CSS en el archivo o se olvidaron de cambiar el hashtag en el nombre del archivo java-script. Y cuando hacemos una solicitud al servidor, el navegador piensa que ya tiene este archivo java-script y decide no descargarlo. Y había una versión antigua, faltaba algo. En general, puede haber muchos problemas. Por lo tanto, la práctica de Implementación Continua le permite al menos probar qué sucedería si tomara una imagen de referencia limpia y la cargara en un entorno completamente nuevo. Puedes ver a dónde lleva esto.
Además, cuando integras código entre sí, es decir. entre el comando, esto le permite ver también cómo se ve en la interfaz de usuario.
Uno de los problemas que ocurre cuando se usa mucho java-script básico es que dos desarrolladores declararon precipitadamente una variable con el mismo nombre en el objeto de la ventana. Y luego, dependiendo de tu suerte. Cuyo archivo java-script se extraiga en segundo lugar sobrescribirá los cambios del otro. También es muy emocionante. Entras: una cosa funciona para una persona, otra no funciona para otra. Y es "maravilloso" cuando todo sale a la luz en producción.
La siguiente práctica que tenemos es la de restauración automática, es decir, volver a la versión anterior de la aplicación.
¿Por qué es esto importante para los desarrolladores? Todavía hay quienes recuerdan los lejanos, lejanos años 90, cuando las computadoras eran grandes y los programas pequeños. Y la única forma de desarrollar web era a través de PHP. No es que PHP sea un mal lenguaje, aunque lo es.
Pero el problema era diferente. Cuando implementamos una nueva versión de nuestro sitio php, ¿cómo la implementamos? La mayoría de las veces abrimos Far Manager o algo más. Y cargué estos archivos a FTP. Y de repente nos dimos cuenta de que teníamos un pequeño error, por ejemplo, nos olvidamos de poner un punto y coma o nos olvidamos de cambiar la contraseña de la base de datos, y hay una contraseña para la base de datos, que está en el host local. Y decidimos conectarnos rápidamente a FTP y editar los archivos allí mismo. ¡Esto es solo fuego! Esto es lo que era popular en los años 90.
Pero, si no has mirado el calendario, los 90 fueron hace casi 30 años. Ahora todo está sucediendo un poco diferente. Y trata de imaginar la magnitud de la tragedia cuando te digan: “Nos lanzamos a producción, pero algo salió mal allí. Aquí está su nombre de usuario y contraseña de FTP, conéctese a producción y corríjalo rápidamente allí”. Si eres Chuck Norris, esto funcionará. De lo contrario, corre el riesgo de que, si corrige un error, cometa 10 más. Precisamente por eso esta práctica de volver a la versión anterior le permite lograr mucho.
Incluso si algo malo de alguna manera se metió en algún lugar, entonces es malo, pero no fatal. Puedes volver a la versión anterior que tienes. Llámelo respaldo, si es más fácil percibirlo en esa terminología. Puede volver a esta versión anterior y los usuarios aún podrán trabajar con su producto y tendrá el tiempo de almacenamiento adecuado. Puedes tranquilamente, sin prisas, tomar todo esto y probarlo localmente, arreglarlo y luego subir una nueva versión. Realmente tiene sentido hacer esto.
Ahora intentemos combinar de alguna manera las dos prácticas anteriores. Obtendremos un tercero llamado Gestión de versiones.
Cuando hablamos de Implementación Continua en su forma clásica, decimos que debemos extraer código de alguna rama del repositorio, compilarlo e implementarlo. Es bueno si tenemos el mismo entorno. Si tenemos varios entornos, esto significa que tenemos que extraer el código cada vez, incluso del mismo compromiso. Lo sacaremos cada vez, lo construiremos cada vez y lo implementaremos en un nuevo entorno. En primer lugar, es el momento, porque construir un proyecto, si tienes uno grande y viene de los años 90, puede llevar varias horas.
Además, hay otra tristeza. Cuando compilas, incluso en la misma máquina, compilas las mismas fuentes, aún así no tienes garantía de que esta máquina esté en el mismo estado que estaba durante la última compilación.
Digamos que alguien entró y actualizó DotNet por usted o, por el contrario, alguien decidió eliminar algo. Y luego tienes una disonancia cognitiva de que a partir de esta confirmación hace dos semanas estábamos construyendo una compilación y todo estaba bien, pero ahora parece la misma máquina, la misma confirmación, el mismo código que estamos intentando construir, pero no funciona. . Estarás lidiando con esto durante mucho tiempo y no es un hecho que lo resolverás. Como mínimo, te estropearás mucho los nervios.
Por lo tanto, la práctica de Gestión de versiones sugiere introducir una abstracción adicional llamada repositorio, galería o biblioteca de artefactos. Puedes llamarlo como quieras.
La idea principal es que tan pronto como tengamos algún tipo de compromiso allí, digamos, en una rama que estemos listos para implementar en nuestros diferentes entornos, recopilemos aplicaciones de este compromiso y todo lo que necesitamos para esta aplicación, lo empaquetamos. en un archivo zip y guárdelo en algún lugar de almacenamiento confiable. Y desde este almacenamiento podemos obtener este archivo zip en cualquier momento.
Luego lo tomamos y lo implementamos automáticamente en el entorno de desarrollo. Corremos allí y, si todo va bien, subimos al escenario. Si todo está bien, implementamos el mismo archivo en producción, los mismos binarios, compilados exactamente una vez.
Además, cuando tenemos una galería como esta, también nos ayuda a abordar los riesgos que abordamos en la última diapositiva cuando hablamos de retroceder a la versión anterior. Si accidentalmente implementó algo incorrecto, siempre puede tomar cualquier otra versión anterior de esta galería y anular su implementación en estos entornos de la misma manera. Esto le permite volver fácilmente a la versión anterior si algo sale mal.
Hay otra gran práctica. Todos usted y yo entendemos que cuando revertimos nuestras aplicaciones a una versión anterior, esto puede significar que también necesitamos la infraestructura de la versión anterior.
Cuando hablamos de infraestructura virtual, mucha gente piensa que es algo que configuran los administradores. Y si necesita, digamos, obtener un nuevo servidor en el que desea probar una nueva versión de su aplicación, entonces debe escribir un ticket a los administradores o desarrolladores. Devops tardará 3 semanas en hacer esto. Y al cabo de 3 semanas te dirán que te hemos instalado una máquina virtual, con un núcleo, dos gigas de RAM y un servidor Windows sin DotNet. Usted dice: "Pero yo quería DotNet". Ellos: "Está bien, vuelve en 3 semanas".
La idea es que al utilizar prácticas de infraestructura como código, pueda tratar su infraestructura virtual como un recurso más.
Quizás, si alguno de ustedes está desarrollando aplicaciones en DotNet, haya oído hablar de una biblioteca llamada Entity Framework. Y es posible que incluso haya oído que Entity Framework es uno de los enfoques que Microsoft está impulsando activamente. Para trabajar con una base de datos, este es un enfoque llamado Code First. Aquí es cuando describe en código cómo desea que se vea su base de datos. Y luego implementas la aplicación. Se conecta a la base de datos, él mismo determina qué tablas están ahí y cuáles no, y crea todo lo que necesita.
Puedes hacer lo mismo con tu infraestructura. No hay diferencia entre si necesita una base de datos para un proyecto o si necesita un servidor Windows para un proyecto. Es sólo un recurso. Y puedes automatizar la creación de este recurso, puedes automatizar la configuración de este recurso. En consecuencia, cada vez que desee probar algún concepto nuevo, algún enfoque nuevo, no necesitará escribir un ticket para devops, simplemente puede implementar una infraestructura aislada a partir de plantillas ya preparadas, desde scripts ya preparados e implementarla. ahí todos tus experimentos. Puede eliminar esto, obtener algunos resultados e informar más al respecto.
La siguiente práctica, que también existe y también es importante, pero que pocas personas utilizan, es la supervisión del rendimiento de las aplicaciones.
Sólo quería decir una cosa sobre la supervisión del rendimiento de las aplicaciones. ¿Qué es lo más importante de esta práctica? Esto es lo que la supervisión del rendimiento de aplicaciones es casi lo mismo que reparar un apartamento. Este no es un estado final, es un proceso. Debes hacerlo con regularidad.
En el buen sentido, sería bueno realizar un seguimiento del rendimiento de las aplicaciones en casi todas las compilaciones, aunque, como comprenderá, esto no siempre es posible. Pero, como mínimo, es necesario realizarlo en cada lanzamiento.
¿Por qué es importante? Porque si de repente experimentas una caída en el rendimiento, debes entender claramente por qué. Si su equipo tiene, digamos, sprints de dos semanas, entonces al menos una vez cada dos semanas debe implementar su aplicación en algún servidor separado, donde tenga un procesador, RAM, discos, etc. claramente fijos. Y ejecutar esas mismas pruebas de rendimiento. . Obtienes el resultado. Vea cómo ha cambiado desde el sprint anterior.
Y si descubre que la reducción disminuyó drásticamente en algún lugar, significará que fue solo debido a los cambios que tuvieron lugar durante las últimas dos semanas. Esto le permitirá identificar y solucionar el problema mucho más rápido. Y nuevamente, estas son aproximadamente las mismas métricas con las que puedes medir el éxito de lo que hiciste.
La siguiente práctica que tenemos es la práctica de Gestión de la Configuración. Son muy pocos los que se toman esto en serio. Pero créanme, en realidad esto es algo muy serio.
Hubo una historia divertida recientemente. Los muchachos se acercaron a mí y me dijeron: "Ayúdenos a realizar una auditoría de seguridad de nuestra aplicación". Miramos el código juntos durante mucho tiempo, me contaron sobre la aplicación y dibujaron diagramas. Y más o menos todo era lógico, comprensible, seguro, ¡pero había uno PERO! Tenían archivos de configuración en su control de fuente, incluidos los de producción con la base de datos de IP, con logins y contraseñas para conectarse a estas bases de datos, etc.
Y les digo: "Chicos, está bien, han cerrado su entorno de producción con un firewall, pero el hecho de que tengan el nombre de usuario y la contraseña de la base de datos de producción directamente en el control de código fuente y cualquier desarrollador pueda leerlos ya es un gran riesgo para la seguridad". . Y no importa cuán segura sea su aplicación desde el punto de vista del código, si la deja en control de código fuente, nunca pasará ninguna auditoría en ningún lado”. De eso estoy hablando.
Gestión de configuración. Es posible que tengamos diferentes configuraciones en diferentes entornos. Por ejemplo, podemos tener diferentes nombres de usuario y contraseñas para bases de datos para control de calidad, demostración, entorno de producción, etc.
Esta configuración también se puede automatizar. Siempre debe estar separado de la propia aplicación. ¿Por qué? Debido a que creó la aplicación una vez, y luego a la aplicación no le importa si se conecta al servidor SQL a través de tal o cual IP o tal o cual IP, debería funcionar igual. Por lo tanto, si de repente uno de ustedes todavía está codificando la cadena de conexión en el código, recuerden que los encontraré y los castigaré si se encuentran en el mismo proyecto que yo. Esto siempre se coloca en una configuración separada, por ejemplo, en web.config.
Y esta configuración ya se gestiona por separado, es decir, este es exactamente el momento en que un desarrollador y un administrador pueden venir y sentarse en la misma sala. Y el desarrollador puede decir: “Mira, aquí están los binarios de mi aplicación. Trabajan. La aplicación necesita una base de datos para funcionar. Aquí al lado de los binarios hay un archivo. En este archivo, este campo es responsable del inicio de sesión, este es de la contraseña, este es de la IP. Implementarlo en cualquier lugar." Y es simple y claro para el administrador. Puede implementarlo realmente en cualquier lugar administrando esta configuración.
Y la última práctica de la que me gustaría hablar es una práctica que está muy, muy relacionada con las nubes. Y aporta el máximo efecto si trabaja en la nube. Esta es la eliminación automática de su entorno.
Sé que hay varias personas en esta conferencia de los equipos con los que trabajo. Y con todos los equipos con los que trabajo, utilizamos esta práctica.
¿Por qué? Por supuesto, sería fantástico si cada desarrollador tuviera una máquina virtual que funcionara 24 horas al día, 7 días a la semana. Pero quizás esto sea una novedad para ti, quizás no prestaste atención, pero el propio desarrollador no trabaja 24 horas al día, 7 días a la semana. Un desarrollador suele trabajar 8 horas al día. Incluso si llega temprano al trabajo, almuerza mucho y luego va al gimnasio. Que sean 12 horas al día cuando el desarrollador realmente utilice estos recursos. Según nuestra legislación, tenemos 5 de los 7 días de la semana que se consideran laborables.
En consecuencia, entre semana esta máquina no debería funcionar las 24 horas, sino solo 12, y los fines de semana esta máquina no debería funcionar en absoluto. Parecería que todo es muy sencillo, pero ¿qué es importante decir aquí? Al implementar esta práctica simple en este cronograma básico, le permite reducir el costo de mantenimiento de estos entornos en un 70 %, es decir, tomó el precio de su desarrollo, control de calidad, demostración y entorno y lo dividió por 3.
La pregunta es ¿qué hacer con el resto del dinero? Por ejemplo, los desarrolladores deberían comprar ReSharper si aún no lo han hecho. O organizar un cóctel. Si anteriormente tenía un entorno en el que tanto el desarrollador como el control de calidad pastaban, y eso es todo, ahora puede crear 3 entornos diferentes que estarán aislados y las personas no interferirán entre sí.
Respecto a la diapositiva con medición continua del desempeño, ¿cómo podemos comparar el desempeño si en el proyecto teníamos 1 registros en la base de datos, dos meses después hay un millón? ¿Cómo entender por qué y cuál es el sentido de medir el desempeño?
Esta es una buena pregunta, porque siempre se debe medir el rendimiento con los mismos recursos. Es decir, implementa un código nuevo y mide el rendimiento del código nuevo. Por ejemplo, necesita probar diferentes escenarios de rendimiento, digamos que desea probar cómo se desempeña la aplicación con una carga liviana, donde hay 1 usuarios y el tamaño de la base de datos es de 000 gigabytes. Lo mediste y obtuviste los números. A continuación tomamos otro escenario. Por ejemplo, 5 usuarios, tamaño de base de datos de 5 terabyte. Recibimos los resultados y los recordamos.
¿Qué es importante aquí? Lo importante aquí es que dependiendo del escenario, el volumen de datos, el número de usuarios simultáneos, etc., puedes toparte con ciertos límites. Por ejemplo, hasta el límite de una tarjeta de red, o hasta el límite de un disco duro, o hasta el límite de las capacidades del procesador. Esto es lo que es importante que usted comprenda. En diferentes escenarios te topas con ciertos límites. Y necesitas entender los números cuando los alcanzas.
¿Estamos hablando de medir el rendimiento en un entorno de prueba especial? Es decir, ¿esto no es producción?
Sí, esto no es producción, es un entorno de prueba, que siempre es el mismo para que puedas compararlo con mediciones anteriores.
Lo tengo, gracias!
Si no hay preguntas, creo que podemos terminar. ¡Gracias!
Fuente: habr.com