Branch builds doesn't work well in practice since it either results in one environment per build which is impractical or no actual deployment which means you are only testing a local copy of the code.
No? I mean... how you setup your build pipeline is entirely up to you... Atleast for web development its pretty easy to add a deployment step to your build pipeline that puts the compiled code in an environment that's a reflection of production (e.g. running the same services (or copies of them) that are running in production). You can control which environment you deploy in by adding environment flags in your code, like dev, staging, prod or whatever works for you.
Unfortunately undoing commits is another bad practice that should be avoided. When a pipeline fails you should fix the code, not undo the work that was already done.
Yes, thats nice in theory, but in practice I've seen many occassions where the dev team was not able to fix the code in a timely fashion and had to revert, in order to be able to continue other work.
The whole premise of Continuous Integration is that when a developer breaks a build they and anyone else who wants to fix it do so immediately.
That sounds like a blocking proces to me... so now feature 1 cannot be released because feature 2 has broken the pipeline and it needs to be fixed first... In a gitflow-like process that is non-blocking, if the pipeline for feature 1 succeeds it can be released, regardless of whether feature 2 pipeline fails. The way you're describing trunk based development to me right now, sounds like feature 2 would prevent feature 1 from being released, meaning failing to meet deadlines on ALL the work the team was working on.
Code conflicts are so tiny and dealt with so quickly in trunk development that it seems like magic.
I'll have to take your word for it... I don't see any proof of why that would be the case though...
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.
No? I mean... how you setup your build pipeline is entirely up to you... Atleast for web development its pretty easy to add a deployment step to your build pipeline that puts the compiled code in an environment that's a reflection of production (e.g. running the same services (or copies of them) that are running in production). You can control which environment you deploy in by adding environment flags in your code, like dev, staging, prod or whatever works for you.
Yes, thats nice in theory, but in practice I've seen many occassions where the dev team was not able to fix the code in a timely fashion and had to revert, in order to be able to continue other work.
That sounds like a blocking proces to me... so now feature 1 cannot be released because feature 2 has broken the pipeline and it needs to be fixed first... In a gitflow-like process that is non-blocking, if the pipeline for feature 1 succeeds it can be released, regardless of whether feature 2 pipeline fails. The way you're describing trunk based development to me right now, sounds like feature 2 would prevent feature 1 from being released, meaning failing to meet deadlines on ALL the work the team was working on.
I'll have to take your word for it... I don't see any proof of why that would be the case though...
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.