You either have 1 environment per branch, shared environments (which is terrible for knowing what is deployed if you are using multiple branches), or aren't deploying your code. Which of these are you proposing?
I've done it in practice but I'm sure there are always teams that can't just fix their code when it breaks. Normally this happens when teams are making changes that are too big due to lack of automation and continuous delivery.
Yes it is intentionally blocking, and once that is accepted we can talk about how to continuously develop features that don't break pipelines using feature flags and other solutions.
Fair enough, I only write these articles to point at what I think we should be doing. Feel free to give it a try and let me know how it goes.
You either have 1 environment per branch, shared environments (which is terrible for knowing what is deployed if you are using multiple branches), or aren't deploying your code. Which of these are you proposing?
No? Your options are limitless when it comes to building and deploying your code... You're not limited to deploying into a shared environment, each branch can have its own space even though it interacts with other services that might be running in develop/staging/production... that entirely depends on how you set it up yourself...
I've done it in practice but I'm sure there are always teams that can't just fix their code when it breaks. Normally this happens when teams are making changes that are too big due to lack of automation and continuous delivery.
I don't believe in perfect humans... Or perfect devs for that matter. I've seen pipelines fail for the silliest of typos... Everybody makes mistakes, if the whole dev team is blocked and has to fix the pipeline, everytime someone makes a mistake... I just don't see it ending well.
Yes it is intentionally blocking, and once that is accepted we can talk about how to continuously develop features that don't break pipelines using feature flags and other solutions.
If you want to convince me of why trunk based development is better and why intentionally blocking development is better, you're going to have to explain how feature flags and "other solutions" are going to magically fix that.
Fair enough, I only write these articles to point at what I think we should be doing. Feel free to give it a try and let me know how it goes.
I havent heard anything yet thats different from the horrible period that existed before gitflow :P
They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
I never said people are perfect but ignoring pipeline failures and delaying fixes or integration is worse than fixing them immediately. A typo is easy to fix since the person that made the change can just make another change.
Sure, we can get to that. This article was just about identifying that feature branching isn't compatible with continuous integration.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice. Either they are saying gitflow was a misstep or trunk development isn't the same as what was before both.
They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
The solution is to stop thinking there are only three options of deployment, in order to justify dismissing gitflow. I can deploy my feature branch just fine, infact I can deploy each seperate pull request for a feature branch and show the result to my team members or clients and it wont interfere at all with other branches or pull requests that are deployed. But most importantly I can run integration tests on each pull request seperately, without them interfering.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice.
I agree it's sad that they dismissed gitflow and mention a replacement, without explaining how it is actually better. I don't really care what anyone says if they dont offer a better solution and nobody has explained to me yet how trunk development is better than gitflow. If something better comes along that doesn't block the dev process and the release cycle, I'd be happy to switch.
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.
You either have 1 environment per branch, shared environments (which is terrible for knowing what is deployed if you are using multiple branches), or aren't deploying your code. Which of these are you proposing?
I've done it in practice but I'm sure there are always teams that can't just fix their code when it breaks. Normally this happens when teams are making changes that are too big due to lack of automation and continuous delivery.
Yes it is intentionally blocking, and once that is accepted we can talk about how to continuously develop features that don't break pipelines using feature flags and other solutions.
Fair enough, I only write these articles to point at what I think we should be doing. Feel free to give it a try and let me know how it goes.
No? Your options are limitless when it comes to building and deploying your code... You're not limited to deploying into a shared environment, each branch can have its own space even though it interacts with other services that might be running in develop/staging/production... that entirely depends on how you set it up yourself...
I don't believe in perfect humans... Or perfect devs for that matter. I've seen pipelines fail for the silliest of typos... Everybody makes mistakes, if the whole dev team is blocked and has to fix the pipeline, everytime someone makes a mistake... I just don't see it ending well.
If you want to convince me of why trunk based development is better and why intentionally blocking development is better, you're going to have to explain how feature flags and "other solutions" are going to magically fix that.
I havent heard anything yet thats different from the horrible period that existed before gitflow :P
They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
I never said people are perfect but ignoring pipeline failures and delaying fixes or integration is worse than fixing them immediately. A typo is easy to fix since the person that made the change can just make another change.
Sure, we can get to that. This article was just about identifying that feature branching isn't compatible with continuous integration.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice. Either they are saying gitflow was a misstep or trunk development isn't the same as what was before both.
The solution is to stop thinking there are only three options of deployment, in order to justify dismissing gitflow. I can deploy my feature branch just fine, infact I can deploy each seperate pull request for a feature branch and show the result to my team members or clients and it wont interfere at all with other branches or pull requests that are deployed. But most importantly I can run integration tests on each pull request seperately, without them interfering.
I agree it's sad that they dismissed gitflow and mention a replacement, without explaining how it is actually better. I don't really care what anyone says if they dont offer a better solution and nobody has explained to me yet how trunk development is better than gitflow. If something better comes along that doesn't block the dev process and the release cycle, I'd be happy to switch.