Normally I would create a feature branch an merge it as soon as I'm completely done, while doing a lot of pushes to my feature branch on gitlab to prevent data loss in the case my local environment breaks...
Where would I push my unfinished changes while using the "ci way of doing it"?
Except for this question I'm very curious about actually trying these principles ! Seems to be a nice way of working!
Feature flags are a good way of accomplishing this. Has the added advantage that you can try it out in production for real without effecting real users (if you can control them via cookies for instance)
It depends on the feature and does sometimes take some creative thinking and experience, but it's worth the effort.
A recent example in our team is developing a new react component in isolation (e.g not actually integrating on the page per-se) but allowing us to work on it together.
What if a new feature requires a database change which would break the previous logic? In this case Feature flags are worthless and the only way of handling it would be a second (or even one for every feature) database...
Or do I get it wrong and there is also a nice solution to this?
I've found it is usually possible with some creative coding to keep db changes backward compatible and this is usually a much safer way of working anyway - irrespective of how you work
e.g keep the old field, introduce new field, code feature toggles against using both and then once you're happy with the new one you can safely delete.
Sometimes though, maybe something doesn't fit into small iterative changes. I would contest this is rare but if it does... well take the hit. Acknowledge it isn't great in this case. One pair works on the awful thing that is perhaps on a branch for a week. They have to contest with merging things etc. You get through it and move on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you handle unfinished features?
Normally I would create a feature branch an merge it as soon as I'm completely done, while doing a lot of pushes to my feature branch on gitlab to prevent data loss in the case my local environment breaks...
Where would I push my unfinished changes while using the "ci way of doing it"?
Except for this question I'm very curious about actually trying these principles ! Seems to be a nice way of working!
Feature flags are a good way of accomplishing this. Has the added advantage that you can try it out in production for real without effecting real users (if you can control them via cookies for instance)
It depends on the feature and does sometimes take some creative thinking and experience, but it's worth the effort.
A recent example in our team is developing a new react component in isolation (e.g not actually integrating on the page per-se) but allowing us to work on it together.
Hmm seems legit for a new feature/replacement...
But what about database migrations/changes...
What if a new feature requires a database change which would break the previous logic? In this case Feature flags are worthless and the only way of handling it would be a second (or even one for every feature) database...
Or do I get it wrong and there is also a nice solution to this?
I've found it is usually possible with some creative coding to keep db changes backward compatible and this is usually a much safer way of working anyway - irrespective of how you work
e.g keep the old field, introduce new field, code feature toggles against using both and then once you're happy with the new one you can safely delete.
Sometimes though, maybe something doesn't fit into small iterative changes. I would contest this is rare but if it does... well take the hit. Acknowledge it isn't great in this case. One pair works on the awful thing that is perhaps on a branch for a week. They have to contest with merging things etc. You get through it and move on.