Stanford ejecuta una instancia de la base de código de OpenEdX que desarrolla activamente un equipo de ingenieros. Mantenemos nuestra propia bifurcación en github.com/Stanford-Online/edx-plataforma y tratamos de mantener nuestra bifurcación cerca de edX master fusionándonos mensualmente desde el repositorio principal de la plataforma edX de edX (github.com/edx/edx-plataforma). Preferimos enviar el código a través de solicitudes de incorporación de cambios (PR) al repositorio principal de edX, pero a veces eso no es posible, ya que creamos periódicamente funciones personalizadas específicas de Stanford. A través de la iteración, hemos adoptado un proceso de lanzamiento claramente definido que se adapta a los flujos de trabajo tanto para fusionar desde el repositorio principal de edX como para mantener el nuestro propio por separado. dominar rama. Dado que estamos ejecutando un sitio web con una gran cantidad de usuarios, creemos que la estabilidad de los lanzamientos es primordial. Esto significa que nos esforzamos mucho para mantener el código incorrecto fuera del , rama, y el proceso de liberación lo facilita.
A medida que enviamos relaciones públicas a edX y a nosotros mismos, necesitamos tener acceso a los repositorios de edX desde nuestros entornos de desarrollo, por lo que la mayoría de los desarrolladores de Stanford ejecutan entornos git con al menos dos controles remotos (o, a veces, más con controles remotos personales y los de colegas): natural, el repositorio de código de Stanford; y río arriba, el repositorio de código de edX, desde el cual podemos consultar la rama maestra para hacer PRs a edX. También usamos esto río arriba remoto para fusionar los cambios de código de edX durante nuestro proceso de lanzamiento.
Aquí es donde vi la necesidad de un diagrama que explica el proceso de lanzamiento. Soy una persona visual, y dibujar algo es como entiendo las cosas. Aquí está mi diagrama para ayudar a describir nuestro flujo de trabajo de desarrollo y lanzamiento:
Es especialmente útil porque nuestros desarrolladores se turnan para ser responsables de los lanzamientos en nuestro sistema rotativo "Release Master". El diagrama mantiene nuestro ciclo de lanzamiento consistente entre lanzamientos y minimiza los errores.
Aquí hay un plan de lanzamiento usando el diagrama como guía:
1. Primero creamos un rc ramificarse de nuestra rama maestra, tomando cualquier desarrollo que se haya fusionado en dominar desde el último lanzamiento.
1a. Si queremos fusionar el río arriba , ramificarse en el rc rama, lo hacemos aquí.
En este punto, tenemos una versión candidata que podemos probar y, una vez que estemos seguros de que no romperá nada, la instalaremos en nuestras máquinas de producción..
2. Ahora fusionamos rama rc en rama , (Esto debería ser un simple avance rápido; si no lo es, ¡la versión anterior tenía un problema!).
3. Ahora el , rama (y la fusionada río arriba código) se puede fusionar de nuevo en el dominar rama para mantener ambas ramas sincronizadas entre sí.
Observe que las ramas de características se crean a partir de dominar y se fusionó nuevamente para ser lanzado en el ciclo de lanzamiento regular. Las revisiones, por otro lado, se derivan de ,, fusionado de nuevo en ,, inmediatamente empujado a producción, y luego fusionado de nuevo a dominar para mantener la sincronicidad. También fíjate que , cambios y río arriba las fusiones no lo convierten en dominar a menos que se consideren seguros después de la prueba, que aísla dominar de errores también.
¡Y eso es! Usamos este modelo de bifurcación para cada repositorio bifurcado que mantenemos, lo que mantiene todo consistente y predecible.
