7 ms·
Even if all tests pass, it doesn't mean you're ready to ship half-completed features. The features should be on branches not in the deployable code.
by tombell 15y ago
Even if all tests pass, it doesn't mean you're ready to ship half-completed features. The features should be on branches not in the deployable code.
- mseebach 15y agoWhich is why you have configuration switches to turn them on and off. The tests ensure that they don't mess with existing features, the switch makes sure the users can't see them.
- tombell 15y agoI prefer keeping unfinished features out of my deployed code base, so I keep them in branches.
- angersock 15y ago...that's what tagged releases are for? Push code into production, put that version into a tag, and do development on mainline?
- tombell 15y agoSo you end up with a bunch of commits in a random order relating to different things. Lets say person A and person B are working on two features both committing to master. Person A commits some work to master and pushes to origin. Person B commits some work and pushes to origin. Repeat this a few times, now you want to scrap the feature person A is working on. How do you cleanly handle this?
- angersock 15y agoSo, the answer would be to never scrap features (that's why you did proper design beforehand, right?). That said, it seems you are suggesting that the workflow should be centered around rolling back features rather than commits? That being the case, if your feature spans multiple commits, then indeed you have something there. If your feature does not, branching probably isn't needed.
- tombell 15y ago> So, the answer would be to never scrap features (that's why you did proper design beforehand, right?). Sure, if you work in some sort of enterprise or corporate environment.