Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Proposal: Start using feature branches

Ouverte
  • Quelque chose ne va pas ?
#1,292 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
15/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
javascript
Domaine
ci-cd, devops

Piste de recherche

Commencez par examiner le workflow actuel de déploiement de develop-to-staging et develop-to-master décrit ici, y compris la manière dont le dépôt API le suit. Comparez avec l’équipe du projet le workflow proposé de feature-branch et ses implications pour staging. C’est terminé lorsque l’approche de branching et le traitement du déploiement sont convenus et documentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

question

Problem

This applies to our API repository as well.

CodeCorps is a project in big part built by volunteers.

Our current deployment system is as follows:

  • A PR is submitted against develop
  • The PR is approved and merged into develop
  • If the develop build passes, this is deployed to staging
  • When ready, we submit a PR from develop into master
  • When this PR is merged and the master build passes, this is deployed to production

The advantage of this is that the process is quick and deployment is simple. We also only have to manage 2 environments and 2 sets of environment variables.

The disadvantage is, it's not very suitable for large, distributed teams.

Presumably, our volunteer force would like to and would probably be more productive if it worked on multiple features in parallel. When all PRs get merged into a single develop branch, there are bound to be clashes that way.

A potentially more effective approach would be to create a new branch for each feature to be worked on. PRs for that specific feature would be created against that branch and when the feature is ready, we create a PR from that feature branch into develop.

Benefits

A benefit of this approach is, it's easier to define requirements for the feature. For example, with the github connect feature, I had to write out our issues in such a way that the last issue to be resolved is the one which adds the connect button into the web application interface. This is constricting and wastes potential volunteer time, since that issue has to be marked as blocked until everything else is ready.

In addition to that, with the API, in the current system, it's difficult to add any new feature piece by piece. We generally do not want to open up API endpoints until everything else about it is ready, but we are sort of forced to do so. With a feature-branch based approach, this would not be a problem.

Disadvantages

It's difficult, though it might be possible, to maintain staging-deployment on feature branches. I'm not sure if I'm stating this clearly, but by that, I mean that, when submitting a PR against a feature branch and then merging into it, it would be difficult to configure our system to deploy that feature branch build onto a staging server of some sort. We'd have to have separate staging servers for each feature branch, with separate environment variables.

There may be a way to set things up so that the default staging server is somehow cloned onto a temporary feature branch server, but I've never tried anything like that, so I'm not sure. Could use some expert advice here.

That being said, the whole thing might not be necessary. develop would remain as is, so we just keep deployment as is. Feature branch has no staging. When we deem it ready, we merge into develop, which goes to staging.

Another disadvantage is we'd have to keep feature branches up to date from develop. Again, that might not be a huge deal, since we presumably would not be creating the final feature -> develop PR until we're done with the feature. At that point, we simply rebase and that's it.

Langage dominant
JavaScript
Étoiles
120
Forks
75
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de code-corps/code-corps-ember

Toutes les issues de code-corps/code-corps-ember

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.