Nuestra configuración es en gran medida guiones de shell internos. Dirijo una microempresa y, a pesar de lo interesante que suenan muchas de las soluciones de implementación de CI y CD, de todos modos son probablemente complementos probados en lo que hago …
El paso 1 es crear un entorno reproducible, ya sea a través de virtualenv, o docker, o vagabundo, incluso un script de shell que configura un entorno si para empezar sabes que el entorno está limpio.
El paso 2 es asegurarse de configurar las pruebas para ese entorno, ya que no tiene sentido ejecutar pruebas de código si el entorno no está en el estado correcto (lo siento, usuarios de Windows, su modelo de implementación del sistema operativo apesta, debe usar herramientas costosas aquí).
- ¿Quiénes son los principales desarrolladores de Ruby on Rails en Singapur?
- ¿Qué es Qallout?
- ¿Cuáles son las mejores aplicaciones web de gestión de proyectos?
- ¿Cuál es el mejor marco para la aplicación web alojada en una PC con Windows, la base de datos es MSSQL, en una intranet?
- ¿Por qué ya no está de moda poner una captura de pantalla de su aplicación en la página de inicio de su sitio web de promoción?
El paso 3 es verificar desde el código fuente-control, ejecutar nuestras pruebas unitarias, seguidas de pruebas funcionales, generar un informe. Querrá repetir esto con diferentes configuraciones, pero básicamente es CI.
El paso 4 es organizar esto en un área con una copia de los datos de cada cliente. Lo ideal sería replicar eventos desde el sitio de producción y ver si las instantáneas de la base de datos divergen (todavía no tenemos eso, básicamente ejecutamos nuestras pruebas en nuestras instantáneas como una solución para hombres pobres).
El paso 5 es obtener la autorización del cliente e implementar la actualización.
El ciclo de vida de una actualización puede ser un día (hot-fix), una semana (falla menor), algunos meses (error, función, trabajos a medida). Una vez que se libera, debe controlar sus aplicaciones para asegurarse de que no haya errores de producción. Hemos estado libres de errores usando este enfoque en nuestro paquete SaaS desde octubre de 2014; ya no somos tan visibles para nuestros clientes, pero también nuestros fines de semana son nuestros, podemos trabajar en cosas nuevas en lugar de perseguir nuestras propias colas 24/7.
No necesita Jenkins, ni Travis ni ninguna otra solución; ¡incluso si están fuera de su alcance, trabaje con lo que tiene, ahorre una hora a la vez hasta obtener un entorno que funcione para usted!
También para su información: realmente odio leer “use Jenkins” porque no responde, no describe nada, ni razonamiento, ni siquiera un proceso de alto nivel, ¡no es un verbo!
