0

I was reading this answer in trying to understand how to work with multiple developers working on multiple branches of a project. My first reflex was to want Jenkins to run a separate build for each branch, but as I understand it, this is a bad way to approach the problem.

Now, I see how having very small features or parts of features which get merged back into the main branch often is the preferred way to go, but I can't quite wrap my head around what happens when a project goes through a very large architectural change.

Say I have a web project written in AngularJS and the team decides that for the future of the project, it needs to be moved over to using ReactJS instead. Said current project would have a reasonable number of features already implemented and tested. At this point, I can't imagine any smaller increment for the new "feature" of using ReactJS other than having it be on part with the current state of the project, meaning every test currently passing should still pass once it's done. Anything else would mean a regression for the project and I know of very few clients who would be ok with this.However, that's hardly going to be the case until the switch is almost 100% done, which will not be a small amount of work.

I might not understand the concept perfectly, but I don't see feature toggles working here (especially if the move to ReactJS requires we modify, say, the Gruntfile since that will inevitably break things a lot). Does the team doing the migration simply needs to tell the rest of the team not to touch the project until they say it's ok? That seems like a weird solution to me.

So I'll admit, I'm at a loss as to what the proper workflow would be here. Any input would be appreciated as our development process is something I constantly try and make better, even with my limited experience in the field.

Community
  • 1
  • 1
gCardinal
  • 632
  • 2
  • 9
  • 27
  • A feature toggle implies doing it both ways, and being able to switch between the two. Is that what you're after? – Robert Harvey Jul 13 '15 at 20:32
  • When you say "increment," do you mean "iteration," as in scrum or some other agile methodology? – Robert Harvey Jul 13 '15 at 20:32
  • I think what you're looking for is a new "branch." It wouldn't ever be merged into the original branch. Rather, the new branch will become the main branch at some point. – Robert Harvey Jul 13 '15 at 20:33
  • By increment, I meant a smaller feature that is part of what the final feature would be. An example would be an admin panel: the login form would be a small part of the feature and adding users would be an other. All the way until we have a fully featured admin panel, this way we always have a small deliverable. I'm sure I messed up and "increment" is not the word I'm looking for, but English is not my native language and I can't think of a better word to explain this. – gCardinal Jul 13 '15 at 21:08
  • As for the new branch, that's also what I'm thinking, but then what about new features added to the "old" architecture? This is all theoretical right now, but I like to challenge myself about our current team's workflow. I'm thinking about a scenario where the client still needs his product updated while we're rewriting his application (because he's still actively using it). – gCardinal Jul 13 '15 at 21:12
  • The new branch would need to implement those new features that got added while it's being developed. How do I prevent a scenario where every time they manage to be up to date, something new got added? Right now I'm thinking I shrink down the team working on the old version, the larger team should then easily be able to catch up. What do you think? – gCardinal Jul 13 '15 at 21:12
  • I think you need a third branch for new features common to both branches. I also think this is a nightmare. – Robert Harvey Jul 13 '15 at 21:16

0 Answers0