3 ms·
If master is currently in production, a good way to do frequent deploys for code that's "not quite ready yet" is to use a feature toggle. This allows you to do
by swalsh 10y ago
If master is currently in production, a good way to do frequent deploys for code that's "not quite ready yet" is to use a feature toggle. This allows you to do partial feature deploys, but block any code paths from using it. Plus when it's time to start directing traffic towards that code path you can turn it off, if you find a bug you missed during testing.
- MatekCopatek 10y agoThis only works for isolated features. As soon as it's some kind of refactoring or a feature that affects a lot of existing code, it's not viable anymore.
- mbrock 10y agoIf you really want to, you can often find ways to do continuous integration even in such cases. For the most brute force example, you could copy the whole program and make a runtime switch for deciding which to run.
- TheCoelacanth 10y ago> you could copy the whole program and make a runtime switch for deciding which to run Wouldn't that make merges even worse, not better?
- cyberpunk 10y agoThen you should be rebasing the branch often from master so that this is less painful when the flip happens. If there is an army of devs working on the same repo then it should be communicated out really obviously. If a dev is planning on submitting code that'll be merged after the massive branch gets into master then they can just rebase from the feature branch and any conflicts should be fixed in those branches...