2

We're a small team (5-6 developers) building a Drupal 7 site. Previously, we've used Features (https://www.drupal.org/project/features) to export our configurations from development to production. We've relied largely on assigning developers discrete, unrelated tasks.

Our upcoming work has distinct, but related development. For example, I anticipate we'll need to add fields that will be used by two different tasks (for example, think about a date field for an event. One developer is working on the email invite and the other is working on the event display page). If we are able to anticipate this overlap, we'd be able to do this before either starts work.

However, if we don't realize a common need until after work has begun in separate branches per developer/feature, this becomes trickier. I believe that we would need to merge their branches together to access the common code-which defeats the point of us having separate branches in the first place.

Curious for what you'd suggest or has worked well in the past! Thanks!

Note: I've identified these potential solutions, both with drawbacks:

  • Cherry pick commits. While this could be helpful, it's also likely that a cherry-picked commit will include extraneous changes beyond the narrow scope needed here. And it's just as likely that the single commit won't include all of the changes necessary (For example, if one commit created the feature, and a second created the field, you'd need to cherry pick both commits). This all seems to head for a merge headache down the road.

  • Create a folder within sites/all/features/ignore, manually transfer the needed features there from the other branch. Include this directory in .gitignore. I don't like that:

  1. This has our team sending features files all over outside of git,
  2. That it could introduce dependency errors if features are changed in the original, but not updated in the other places that they are used,
  3. That users may make changes to the ignored features that aren't moved into git,
  4. That switching between computers/development environments would lose these files
  5. That all related branches would need to be merged before deploying to production (which again, undermines the point of branching since these branches are now dependent on each other and would have to be released at once, rather than when ready/needed).
  • Another option is to make the change (export the feature needed or cherry-pick commits) to the parent branch (e.g., Develop or Develop-Feature) so that it's available to all child branches.
5
  • 7
    This isn't the answer you are looking for, but in all honesty, I wouldn't suggest starting a new site on Drupal 7 at this point. Its EOL is Nov 2022, only a year and some from now. After that Drupal 7 won't receive security updates anymore, and the upgrade from D7 -> D8 is NOT easy. On top of this, the configuration management API in D8 is easier than D7 Features (morpht.com/blog/drupal-8-configuration-part-1-configuration-api). I'd recommend starting new sites in D9. Most every module has already upgraded from D8 -> D9 as the upgrade process is significantly easier.
    – Jaypan
    Jun 12 at 5:15
  • 1
    Sorry for not clarifying! This isn't a new site. I've started new sites in D9, and agree that it is way easier/nicer, and while D9 can do 99% of what we need, the 1% is pretty key (mostly Rules related). We're building things in a D9 friendly way to mitigate the migration pains, while also trying to build some skill on our team to be comfortable with D9 (including, for example, moving to git). I imagine this question still applies to D9 sites (outside of features), and seems like cherry picking commits is the ideal approach. Jun 12 at 5:58
  • 2
    Consider Composerizing the site to manage contrib and core. Provide a way developers can easily sync the latest Live DB into their local site. Everytime a developer starts a new feature branch (or switches branches) or merges develop in to an existing feature branch they sync the latest Live DB into their local site and have to run composer install, drush updb and drush fra. Keep feature branches small, everybody must provide a merge/pull request with a stable state by the end of a working day. Ignore front-end build files from the repo. Leave that to the CI.
    – leymannx
    Jun 12 at 9:10
  • Make Composer scripts, custom Drush commands, variable_get/_set() and hook_update_N() your best friends.
    – leymannx
    Jun 12 at 9:14
  • 3
    I can't think of a need for Rules as a blocker to upgrading. You can likely recreate many of those rules in a few lines of code/Events or use business rules.
    – Kevin
    Jun 12 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.