Estamos haciendo un proyecto en la nube para el desarrollo, una plataforma que puede simplificar la vida a los desarrolladores, desarrolladores, evaluadores, líderes de equipo y otros especialistas involucrados en el proceso de desarrollo tanto como sea posible. Este producto no es por ahora y no es para mañana, y la necesidad de esto solo se está formando.
La idea principal es que puede implementar la canalización con herramientas preconfiguradas, pero al mismo tiempo con la posibilidad de realizar una serie de configuraciones, todo lo que necesita hacer es implementar el código.
¿De dónde viene esa perversión? Vemos una tendencia clara de que ahora la velocidad de despliegue de nuevos proyectos afecta al mercado. El comercio depende de la rapidez con la que se entregan los lanzamientos. De qué tan rápido se corregirán los errores, qué tan rápido se involucrarán nuevos nichos. A principios de 2018, la compañía global "451 Research" realizó una encuesta sobre qué tecnologías serán una prioridad para el desarrollo. Los diez primeros incluyen tecnologías de creación y administración de contenedores, así como arquitectura de aplicaciones sin servidor y microservicios, superando incluso un tema tan exagerado como blockchain.
Y ahora tenemos un par de preguntas para ti.
Gráfico de la encuesta:
¿Es necesario?
El uso de contenedores en el desarrollo de un nuevo producto tiene sus ventajas y desventajas. El uso o no de esta tecnología debe decidirse en función de las tareas establecidas. Para algunas tareas, no se puede prescindir del uso de contenedores, y para algunos son simplemente superfluos. Por ejemplo, para sitios con poco tráfico, una arquitectura simple de dos servidores será suficiente. Pero si se planea un crecimiento de desarrollo significativo, así como un gran aumento de visitantes en poco tiempo, entonces en este caso vale la pena considerar la infraestructura que utiliza contenedores.
El uso de contenedores tiene varias ventajas:
- Cada aplicación se ejecuta de forma aislada en su propio contenedor, lo que minimiza los problemas relacionados con la configuración.
- La seguridad de la aplicación también se logra aislando cada contenedor.
- Debido al hecho de que los contenedores usan el núcleo del sistema operativo, ahora no se necesita el SO huésped, por lo que se libera una gran cantidad de recursos.
- Además, debido al uso del kernel del sistema operativo y porque no necesita confiar en el hipervisor, los contenedores requieren muchos menos recursos en comparación con otras pilas.
- Nuevamente, debido a que los contenedores no requieren un sistema operativo invitado, son fáciles de migrar de un servidor a otro.
- Debido al hecho de que cada aplicación se ejecuta en un contenedor aislado, es fácil transferirla desde la máquina local a la nube;
- Es muy "barato" iniciar y detener el contenedor debido al uso del núcleo del sistema operativo.
En relación con todo lo anterior, creemos que la tecnología de contenedorización es actualmente la pila más rápida, más eficiente en recursos y más segura. Debido a las ventajas de los contenedores, puede tener el mismo entorno tanto en la máquina local como en la producción, lo que facilita el proceso de integración continua y entrega continua.
Los beneficios de los contenedores son tan convincentes que definitivamente se utilizarán durante mucho tiempo.
¿Qué tiene que ver la nube con el desarrollo?
En el mundo ideal del desarrollador, cualquier código de compromiso debe implementarse con solo presionar un botón, como por arte de magia.
Lo tuvimos de esta manera: hay un Gitlabchik con tareas y una fuente. Cuando necesites recolectar algo: GitLab Runner. Trabajamos en Git Flow, todas las funciones en ramas separadas. Cuando una rama ingresa al repositorio, las pruebas de este código se inician en GitLab. Si se pasan las pruebas, el desarrollador de este hilo puede hacer una solicitud de fusión, de hecho, una solicitud de revisión de código. Después de la revisión, la rama es aceptada, fusionada en la rama de desarrollo, las pruebas pasan por ella nuevamente. Al implementar, GitLab Runner recoge el contenedor Docker y lo pasa al servidor de ensayo, donde se puede hacer clic y alegrarse. Y aquí está la primera mordaza: miramos a través del código con nuestras manos para cumplir con lo funcional y esto es lo primero que solucionamos. Después de eso, inyectamos el código en la rama de lanzamiento. Y para ella, estamos lanzando una versión preproductiva separada de nuestra solución, que nuestros clientes comerciales están observando. Una vez que la versión está preinstalada en la preproducción, la pasamos a producción y pasa a los nodos del producto. Hay notas de lanzamiento e informes de errores generados automáticamente. La velocidad de montaje fue de más de 30 minutos, ahora es un orden de magnitud menor. Hemos seleccionado un conjunto de herramientas para nosotros y ahora estamos pensando en cómo hacer el mismo SaaS listo para usar.
Para nosotros, el proceso de lanzamiento típico para el lanzamiento es el siguiente:
- Establecer objetivos para la implementación de nuevas características
- Localización de código
- Realizar cambios de acuerdo a las tareas. Escribir pruebas automatizadas antes de la compilación.
- Verificación de código, tanto manual como autocomprobación
- Fusionar código en una rama de desarrollo
- Construye una rama de desarrollo
- Implementar infraestructura de prueba
- Implementar versión en infraestructura de prueba
- Ejecución de pruebas, funcional, integración, etc.
- En caso de errores, termínelos inmediatamente en la rama de desarrollo
- Migrar una rama de desarrollo a una rama maestra
Aquí hay un diagrama con detalles para nuestro proceso:
En realidad, la primera pregunta: díganos dónde rastrilla qué tipo de rastrillo era y qué tan universal o no es este esquema. Si usa un flujo de trabajo que es muy diferente a este, agregue algunas palabras, por qué, por favor.
¿Qué tipo de producto estamos planeando?
Decidimos no copiar a Amazon a este respecto, sino llevar a cabo nuestro desarrollo teniendo en cuenta las características específicas del mercado. Inmediatamente haga una reserva de que todos los cálculos son nuestra opinión subjetiva basada en nuestro análisis. Estamos abiertos a un diálogo constructivo y estamos listos para cambiar la hoja de ruta del producto.
Al analizar la tubería existente de Amazon, llegamos a la conclusión de que tiene capacidades tremendas, pero el énfasis está en equipos corporativos muy grandes. Nos pareció que para implementar un microservicio en Docker, es irrazonablemente largo, más que si, por ejemplo, se implementara en Kubernetes, porque hay un lugar para configurar configuraciones internas, definir acuerdos internos, etc. y todo esto necesita ser entendido por mucho tiempo.
Por otro lado, existe, por ejemplo, Heroku, donde puede implementar con un solo clic. Pero debido al hecho de que los proyectos, como regla, están bastante ramificados, con microservicios de terceros, en algún momento se hace necesario desplegar imágenes acopladas personalizadas con servicios DBaaS y todo esto no encaja en Herocku porque es costoso Ya sea incómodo.
Queremos encontrar otra opción. La media dorada. Dependiendo del tipo de proyecto y tareas, proporcione un conjunto de herramientas ya preconfiguradas que ya están integradas en una sola tubería, mientras deja la posibilidad de un cambio profundo en la configuración y la capacidad de reemplazar las herramientas en sí.
Entonces, ¿qué será?
Ecosystem, que incluye un portal y un conjunto de herramientas y servicios para minimizar la interacción de los desarrolladores con el nivel de infraestructura. Define parámetros ambientales que no están vinculados al entorno físico:
- Entorno de desarrollo (sistema de gestión de configuración, sistema de configuración de tareas, repositorio para almacenar código y artefactos, rastreador de tareas)
- CI - Integración continua (ensamblaje, infraestructura y orquestación)
- QA - Garantía de calidad (pruebas, monitoreo y registro)
- Puesta en escena: entorno de integración / bucle de prelanzamiento
- Producción - Circuito productivo
Al elegir las herramientas, nos centramos en las mejores prácticas del mercado.
Construiremos la infraestructura con Stage y Prod usando Docker y Kubernetes con función de desempolvado paralelo.
Esto sucederá de forma iterativa: en la primera etapa, se planifica un servicio que le permitirá tomar el archivo Docker del proyecto, luego recopilar el contenedor requerido y presentarlo a Kubernetes.
También planeamos prestar especial atención al servicio para monitorear el proceso de desarrollo y la entrega continua. ¿Qué queremos decir con este servicio? Esta es una oportunidad para crear un modelo jerárquico de KPI con indicadores como% de cobertura por pruebas unitarias, tiempo promedio para eliminar un incidente o defecto, tiempo promedio desde el compromiso hasta la entrega, etc.
La recopilación de datos de origen de diferentes sistemas: sistemas de gestión de pruebas, gestión de tareas, componentes de CI / CD, herramientas de monitoreo de infrarrojos, etc.
Y lo más importante es mostrar en una forma adecuada disponible para un análisis rápido: paneles con la posibilidad de desglose, análisis comparativo de indicadores.
Que queremos hacer
En realidad, me gustaría saber de usted acerca de todo esto y nuestros planes de pasos. Ahora ellos son:
- Infraestructura y orquestación - Docker & Kubernetes
- Configuración de tareas, almacenamiento de código y artefactos, rastreador de tareas - Gitlab, Redmine, S3
- Producción y desarrollo - Chef / Ansible
- Asamblea - Jenkins
- Pruebas: selenio, LoadRunner
- Monitoreo y registro - Prometheus y ELK
- Por cierto, ¿cómo ve si dentro de la plataforma habrá una opción? Si quisiera, eligió Jenkins, no quiso, ¿GitLab Runner?
- ¿O no importa lo que hay dentro, lo principal es que todo está correctamente construido, probado y desplegado?
¿Cómo se puede ayudar?
El producto será desarrollado para desarrolladores nacionales. Si ahora nos dice cómo hacerlo, es probable que se incluya en el lanzamiento.
Por favor, dime qué pilas estás usando en este momento. Puede - en los comentarios o por correo electrónico a team@ts-cloud.ru.
UPD: por conveniencia, hicimos un breve cuestionario en forma de Google,
aquí .
Además, lo mantendremos actualizado con el desarrollo, y en algún momento le daremos a los participantes asistentes acceso a beta (de hecho, acceso gratuito a buenos recursos informáticos de la nube a cambio de comentarios).