Comments by "Andrea Laforgia" (@andrealaforgia) on "Continuous Delivery"
channel.
-
@clickrush >processes and tools cannot substitute communication and engagement with your coworkers. There is not one size fits all, no silver bullet is what I'm getting at.
Again, this is a typical logical fallacy, black&white reasoning. Who ever said that CI is a "silver bullet"? CI is a way of working that has proven to be better than other ways of working to develop software. Period. No one has ever stated, in any books/resources/articles about CI, that CI is a "silver bullet". People keep rejecting CI and trunk-based development putting a lot of emphasis on communication, like communication were the only thing a team needs in order to deliver software. A team needs to be able to continuously integrate their work. That's the point. CI is not substituting communication and engagement with your coworkers.
How is a long-lived feature branch approach fostering any communication, given that it's a way to hide your changes and silo your development? Developers adopting feature branches often do not communicate for days and days, only to discover problems at the time of merging their changes.
>The beauty of git is that is doesn't inherently prevent you from merging or branching.
I don't see that as a "beauty". This video is not about git, it's about GitFlow. It's different.
>Saying that rule/methodology X simplifies things begs the question: Under what circumstance?
How much do you know about CI, which has been going on for almost 2 decades, and all the studies about it that prove it's the best way to develop software we know so far? Read "Accelerate".
1
-
@clickrush >I wasn't arguing against CI generally. I was questioning the notion that one particular way of using git "represents reality" for all
I see a contradiction there. CI does dictate "one particular way of using your VCS". The definition of CI is "practice of merging all developers' working copies to a shared mainline several times a day" so if you're not questioning CI, you shouldn't be questioning trunk-based development either, cause CI and TBD are the same thing. Nobody is saying that this particular way of using git represents reality for all. What has been said is that if you want to implement CI, you need to give up ways of working that are antithetical to CI, and GitFlow is one of them for the reasons exposed. You are still free not to do CI, though.
>What may happen if you don't separate work into branches on the VCS level is that you are separating it on the code level. You introduce configuration and (ad-hoc) logic in your code base so you can accommodate staging environments, beta/prototype features and so on. Which means you need to test that code too, which means you blow up your code base just so you can avoid branching.
Absolutely not. Have you actually ever tried trunk-based development + feature toggles? It's much easier than you'd think. When feature toggles are inactive, you can consider the code they hide as not there at all.
Separating the code physically (feature branches) offers less benefits than separating it logically (feature toggles). The latter approach at least makes sure that the various streams of development are integrated, the former doesn't, and the longer those branches live, the more they diverge from each other and master, the riskier it becomes to merge them into master. You can switch features on in your specific test environment and do all you want. It's much cleaner and simpler. The ability to integrate work and the ability to test/release features are two different aspects of software development.
Note that you say "you blow up your code base just so you can avoid branching". First, you don't blow up at all your code base, quite the contrary. Second: the purpose here is not to avoid branches, but to fulfil the definition of CI. The fact that branches are avoided is a nice side effect.
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
Waterfall has never been the answer. There is a common misunderstanding in the industry that Waterfall is a “model”. No one — and I mean no one — in the history of software engineering has ever presented a “Waterfall model”. The idea that software had to be developed in subsequent phases was adopted by the US DoD. They never understood that what Dr. Winston Royce was presenting in his 1970 paper on how to manage the development of large systems was a model to avoid (he wrote something along the lines of “don’t do it this way, it invites failures”) and proceeded to explain how to produce those systems iteratively. He even mentions involving the customer in a very similar way to what the Agile Manifesto describes. Royce himself was a supporter of iterative and incremental methods. The industry understood the opposite and a “Waterfall model” dominated it for 20 years, until the adaptive methods reemerged and Agile was formalised. We have always knows, however, that software should never be implemented with a “Waterfall model”.
Customers don’t need predictability. That’s an extremely common fallacy. Customers need a software that solves their problems. They only need predictability when needing predictability is the only option we give them. If you ask me for a software, and I tell you that you’re going to get it at some point in the far future, then of course you want to understand how long it’s going to take and how much it’s going to cost you, before you embark on a journey where you won’t see results for a long time. If, on the other hand, I agree with you to release limited-scope features continuously, frequently, so you can evaluate them, give feedback and adjust, limit your financial exposure, and decide, at each step, if you want to continue investing in the product or not, you are not going to need predictability. Remember: “Waterfall” was never a model for software development. We have known that software must be developed in iterative and incremental ways for 70 years now.
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
When I talk about continuous delivery, I always think of complex flows. Continuously integrating changes into main/master and releasing features to production are two different concepts. Clearly, if you adopt an Agile way of working, you'd want to deliver as often as possible, but you can schedule releasing specific features, as long as they are present in the code but hidden behind feature flags.
When you release a new version of your product, all you need to do is tag your code. You don't need to create a release branch at that point in time (tags are logical branches). When it comes to hotfixing v.1.0.0, then you can create a branch, apply the hotfix to main, apply the hotfix to the branch, release version 1.1.0 whilst main/master happily navigates towards v.2.0.0. But that branch is not for continuous integration. It's for hotfixing. And what you really want is to converge that version into the main one asap. I would much prefer continuously delivering and not having to maintain multiple concurrent versions, parked on side tracks for ages. If you have hundred/thousand customers, that model becomes unsustainable. So, yes, you can achieve what you mention by having a single branch for continuous integration and deciding when to release features as a parallel process.
1
-
1
-
No, Kanban, strictly speaking, is not Agile.
As Ron Jeffries, one of the signatories of the Manifesto, wrote:
"Is Kanban “Agile”? In a word, no. In a few more words, while Kanban can be used in an Agile fashion, its principles are not those of the Agile Manifesto, and it can be used quite effectively in a situation where the Agile values are not in place. It’s a really good set of ideas, very compatible with Agile projects, very likely to help you improve. But it’s not “Agile”: it’s an independent set of ideas. Great ideas."
Consider that founding principles of Kanban originated in the 1940s, when Agile was not even remotely conceivable.
Kanban is orthogonal to Agile and can be used with Agile, but it's not Agile.
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1