3

I work in a small team making software, we run pretty close to scrum, tickets and sprints, and use git. I however work in a different timezone, so communication can be a bit disjointed, though otherwise very good.

Recently I have been working on some tickets that rely on a feature that has not passed PR. This can lead to some substantial changes to my 'base' branch.

At this point I have been working on a branch off of this initial feature branch, only to have it change. Sometimes it changes a great deal. We have been 'getting around' this using a number of means. Initially, closing the initial PR, and rolling all of the changes and comments into the PR of the second feature.

Currently I have 'taken' the ticket and PR off of another dev, and will make the changes requested whilst keeping second feature branch up to date.

This has caused issues for me, in overhead having to juggle numerous features and keep branches up to date. It has caused issues for the team, there has been confusion over the PR's what goes where who's responsible for what. These have caused some late nights as I work in their timezone to get it all sorted.

I can think of a number of solutions, but none without problems:

  1. Roll features that rely into one another into single tickets an PRs, this way there are no ticket dependencies. However tickets would get huge and unwieldy, PR's would be equally so

  2. Don't work on a feature that has uncompleted predecessors. This way the 'ground state' would not move whilst you work on it. However we try to focus on one task at a time and this leads to having these dependencies, if I waited on these I could waste a great deal of time.

Before the timezone changes we would avoid this by all working on tickets with a great deal of dependencies, and getting it done as quickly as possible. However the time difference makes this hard (24 hour review turn around).

Improve this question
4
  • 2
    To those trigger-happy downvoters: if you downvote a well-written question like this, which is clearly on-topic, it would be really helpful if you leave a comment why you think there is something wrong with this question. Even a close-vote would say more than nothing. Commented Jun 21, 2018 at 14:47
  • 5
    Dammit, what is a "PR"? Pull Request? Public Relations? Passable Rotisserie? Commented Jun 21, 2018 at 14:51
  • can you provide an example feature with dependency? Commented Jun 21, 2018 at 15:01
  • Does "PR" mean "peer review"? Commented Jul 2, 2018 at 19:51

2 Answers 2

Reset to default
4

There's no solution* for the underlying problem of "what if someone changes the code I was working on before I finish my changes", you can only manage the process.

Traditionally feature branches mitigate the problem, because you can work on your version of the code and periodically pull in other peoples changes at your own rate. Fixing the merge issues as you go.

This doesn't help much if you have long lived feature branches with many changes in though as you can be seconds away from completion of months of work when a colleague commits their 3 months worth of changes, leaving you with a mammoth merge and refactoring of all your work.

I would suggest the standard:

  • Smaller features
  • Frequent 'finishing' and merging in the feature branch
  • Loose coupling of code

and maybe you could do some coding up of contracts such as interfaces before you do the implementation. That way the base branch should be ready for your changes, before you do you changes, if that makes sense.

*the solution is of course to get your commit in first and go to lunch.

Improve this answer
3

If you always have a time lag of 24 hours before you get feedback on a pull request, and you run into trouble if it is rejected because your next work depends on it, you want to make it very likely to get your pull requests approved, especially the ones where other work will depend on them.

The first measure I would suggest is to check if it is possible to split up important changes into smaller feature slices. If you can split up a big PR into two smaller ones, the first one including the important changes which are required for implementing other features, the second one containing less important changes, you will increase the chance to get the important changes approved, even if the less important changes are rejected.

Moreover, it should be transparent to the reviewer when a PR is a prerequisite for your next working steps. Your reviewer knows the time lag as well, and he/she should be aware that rejecting important changes just because of some minor formal issues will make things very ineffective. Allowing him/her to repair things like obvious typos, wrong indentation, accidental violation of coding standards. For such issues, you should not have to wait 24 hours to get the changes into the main dev branch.

Finally, feature toggles can be a good way to integrate "half-baked" features. The toggle should activate the feature only in your development environment, but not in the test or production environment.

You add a feature toggle for the "initial feature" that makes it invisible for the users as well as all of the dependent feature sets. This can often make it easier for your reviewer to accept the pull request, as long as the change will not cause any real harm to other parts of the system.

Moreover, by making all new feature slices that depend on the initial change dependent from the toggle, you make the dependency explicit, and don't have to juggle it in your head. The dependency will also become more transparent for the rest of the team.

Of course, to make this work, the reviewer should tell you that he/she accepts your PR for now, but before the feature toggle is finally removed (and the feature-set released into production), he/she expects you to change a list of things. And when you commit the final PR to remove the toggle, he/she can check this list again to make sure nothing was forgotten.

In case the pull request is not accepted either, it will be probably better to work on the issues of the rejection first before you build more code upon it. But even then, having the dependent code checking on the feature toggle will make it easier for you to sort out the feature dependencies.

Improve this answer
13
  • 2
    I gotta say, I don't think feature toggles are a great way to manage change. They introduce unnecessary complexity and complicate testing. If your users don't like you moving their cheese, then sure, provide a feature toggle. The feature toggle is its own feature. But if you're throwing switches in the program so that you can corral your development process, then I would suggest that the development process needs to be fixed. Commented Jun 21, 2018 at 14:54
  • 1
    @RobertHarvey: sure it is a process problem. But the usage of certain tools can help to improve a process. When I introduced the systematic usage of FT into the development process of my team, it helped us a lot to manage parallel and dependend development of features, and to make this more independend from the usual source control integration steps. So I am not speaking about some theory here. Commented Jun 21, 2018 at 15:08
  • 1
    @RobertHarvey: I agree, usage of FTs is probably not the only thing the OP needs to change in their process to make it more smooth. And if FTs are used in a wrong manner, with dozens of checks in the source code if the toggle is activated or not, this can become a problem, too. FTs work best when there is just one feature entry point, and only one or two checks for the toggle are required in the code base. Commented Jun 21, 2018 at 15:15
  • 2
    I don't think he should use feature toggles at all for this. It's papering over a larger problem. It's a good suggestion, but in a sense it's throwing good money after bad. Commented Jun 21, 2018 at 15:22
  • 1
    I would also have written this answer, but would like to point out that feature toggles don't have to be a literal conditional. You could just as well call this “dependency injection”. The point is that you first introduce some abstraction or interface, then can implement a solution within that interface without having to change other code. Afterwards the abstraction can be removed. This fits nicely into the “split your PRs” idea: first refactor to make the change easy (this is the blocker), then you're free to implement the actual features at your leisure. Commented Jun 22, 2018 at 11:08

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.