Stanford exécute une instance de la base de code OpenEdX qu'une équipe d'ingénieurs développe activement. Nous maintenons notre propre fourche à github.com/Stanford-Online/edx-platform et nous essayons de garder notre fork proche du maître edX en fusionnant mensuellement à partir du référentiel principal de la plate-forme edx d'edX (github.com/edx/edx-platform). Nous préférons envoyer le code via des demandes d'extraction (PR) au référentiel principal d'edX, mais parfois ce n'est pas possible, car nous créons périodiquement des fonctionnalités personnalisées spécifiques à Stanford. Grâce à l'itération, nous avons adopté un processus de publication clairement défini qui s'adapte aux flux de travail pour à la fois fusionner à partir du référentiel edX principal et garder le nôtre séparé maître branche. Étant donné que nous gérons un site Web avec un grand nombre d'utilisateurs, nous pensons que la stabilité des versions est primordiale. Cela signifie que nous nous efforçons de garder le mauvais code hors de la libérer branche, et le processus de libération facilite cela.
Comme nous soumettons des PR à edX ainsi qu'à nous-mêmes, nous devons avoir accès aux référentiels d'edX à partir de nos environnements de développement, donc la plupart des développeurs de Stanford exécutent des environnements git avec au moins deux télécommandes (ou parfois plus avec des télécommandes personnelles et celles de collègues): origine, le référentiel de code de Stanford ; et en amont, le référentiel de code edX, à partir duquel nous pouvons consulter la branche principale pour créer des PR vers edX. Nous utilisons également ce en amont remote pour fusionner les changements de code d'edX pendant notre processus de publication.
C'est là que j'ai vu le besoin d'un diagramme qui explique le processus de publication. Je suis une personne visuelle, et dessiner quelque chose est ma façon de comprendre les choses. Voici mon diagramme pour vous aider à décrire notre workflow de développement et de publication :
C'est particulièrement utile parce que nos développeurs sont à tour de rôle responsables des versions dans notre système rotatif "Release Master". Le diagramme maintient notre cycle de publication cohérent entre les versions et minimise les erreurs.
Voici un plan de version utilisant le diagramme comme guide :
1. Nous créons d'abord un rc branche de notre branche principale, en prenant tout développement qui a été fusionné dans maître depuis la dernière version.
1a. Si nous voulons fusionner le en amont libérer branche dans le rc branche, nous le faisons ici.
À ce stade, nous avons une version candidate que nous pouvons tester et, une fois que nous sommes sûrs qu'elle ne cassera rien, installez-la sur nos machines de production..
2. Maintenant, nous fusionnons la branche rc en succursale libérer (cela devrait être une simple avance rapide ; si ce n'est pas le cas, la version précédente avait un problème !).
3. Maintenant, le libérer succursale (et la fusion en amont code) peut être fusionné dans le maître branche pour garder les deux branches synchronisées l'une avec l'autre.
Notez que les branches de fonctionnalités sont créées à partir de maître et fusionné pour être publié dans le cycle de publication régulier. Les correctifs, en revanche, sont dérivés de libérer, fusionné dans libérer, immédiatement poussé à la production, puis fusionné à nouveau maître pour maintenir la synchronicité. Remarquez également que libérer changements et en amont les fusions n'en font pas maître à moins qu'ils ne soient jugés sûrs après les tests, ce qui isole maître des bogues aussi.
Et c'est tout! Nous utilisons ce modèle de branchement pour chaque référentiel bifurqué que nous maintenons, ce qui garantit que tout est cohérent et prévisible.
