4 ms·

Continuous Integration (2024 Update)

33 points by ABS 3y ago

weird_narrator 3y ago
[flagged]
- lionkor 3y ago
  guessing yes since we are all reading it
ABS 3y ago
from https://martinfowler.com/recent-changes.html https://martinfowler.com/recent-changes.html A major revision of Continuous Integration At the turn of the century, I was lucky to involved in several projects that developed the practice of Continuous Integration. I wrote up our lessons from this work in article on my website, where it continues to be a oft-referenced resource for this important practice. Late last year a colleague contacted me to say that the article, now nearly twenty years old, was still useful, but was showing its age. He sent me some suggested revisions, and I used this as a trigger to do a thorough revision of the article, considering every section in the original, and adding new ones to deal with issues that have appeared in the last two decades. During those decades Feature Branching has been widely adopted in the industry. Many colleagues of mine feel that Continuous Integration is a better fit for many teams, I hope this article will help readers assess if this is the case, and if so, how to implement Continuous Integration effectively.
- deleted 3y ago
  [deleted]
i386 3y ago
Still have the first edition of his book on my bookshelf. Wrote code and product managed on two different CI systems (Bamboo and Jenkins). Still cool to see CI evolving!
j4yav 3y ago
I feel like CI to master with pull/merge requests in very short lived feature branches works really well, even better than when everyone tried to merge their in progress work to master. Though, both are certainly better than when you’d work on a release branch for 3 months, try to keep it in sync with master and a few hotfix branches, and then merge it all at once at the end. That was a total nightmare, and was actually really common.
- kitd 3y ago
  I fully endorse your first option, how I used to work. In my latest team, all PRs go through an overworked "code owner" so end up backing up and getting out of date. Breakages in PRs from merging latest master get sent back to me to "fix", ie extra work only required because current master is so behind the curve.
- hasoleju 3y ago
  We also work with feature branches and I try to understand which signs will tell if we have to much integration problems because of the feature branches. Right now we really focus on closing pull requests as fast as possible, but still use feature branches that live for a few weeks. I think the maximum lifetime of a feature branch in our project is 5 weeks. You mentioned very short lived feature branches. What does that mean in your case? A few days or weeks?
  - alkonaut 3y ago
    I do anything from 10 minutes to months depending on the scope. Yes it’s painful to have longer lived branches but when you make a months long branch it’s because the pain of doing it any other way would be greater. Most often the longer lived branches are high cost/risk/reward experiments that may or may not turn out successful. E.g swapping out some component that can’t be done side by side easily (as an example from the real world would be moving from .NET framework to .NET core in a several hundred man-year code base). Most “short” branches I do is 24-48h so typically a half day to a full day of coding then about the same amount of time waiting for reviews and validations.
  - j4yav 3y ago
j4yav 3y ago
What’s actually different in the 2024 update?
- ABS 3y ago
  I posted a note in a comment but was flagged. see https://martinfowler.com/recent-changes.html https://martinfowler.com/recent-changes.html

33 points by ABS 3y ago

weird_narrator 3y ago

[flagged]

lionkor 3y ago
guessing yes since we are all reading it

ABS 3y ago

from https://martinfowler.com/recent-changes.html https://martinfowler.com/recent-changes.html A major revision of Continuous Integration At the turn of the century, I was lucky to involved in several projects that developed the practice of Continuous Integration. I wrote up our lessons from this work in article on my website, where it continues to be a oft-referenced resource for this important practice. Late last year a colleague contacted me to say that the article, now nearly twenty years old, was still useful, but was showing its age. He sent me some suggested revisions, and I used this as a trigger to do a thorough revision of the article, considering every section in the original, and adding new ones to deal with issues that have appeared in the last two decades. During those decades Feature Branching has been widely adopted in the industry. Many colleagues of mine feel that Continuous Integration is a better fit for many teams, I hope this article will help readers assess if this is the case, and if so, how to implement Continuous Integration effectively.

deleted 3y ago
[deleted]

i386 3y ago

Still have the first edition of his book on my bookshelf. Wrote code and product managed on two different CI systems (Bamboo and Jenkins). Still cool to see CI evolving!

j4yav 3y ago

I feel like CI to master with pull/merge requests in very short lived feature branches works really well, even better than when everyone tried to merge their in progress work to master. Though, both are certainly better than when you’d work on a release branch for 3 months, try to keep it in sync with master and a few hotfix branches, and then merge it all at once at the end. That was a total nightmare, and was actually really common.

kitd 3y ago
I fully endorse your first option, how I used to work. In my latest team, all PRs go through an overworked "code owner" so end up backing up and getting out of date. Breakages in PRs from merging latest master get sent back to me to "fix", ie extra work only required because current master is so behind the curve.
hasoleju 3y ago
We also work with feature branches and I try to understand which signs will tell if we have to much integration problems because of the feature branches. Right now we really focus on closing pull requests as fast as possible, but still use feature branches that live for a few weeks. I think the maximum lifetime of a feature branch in our project is 5 weeks. You mentioned very short lived feature branches. What does that mean in your case? A few days or weeks?
- alkonaut 3y ago
  I do anything from 10 minutes to months depending on the scope. Yes it’s painful to have longer lived branches but when you make a months long branch it’s because the pain of doing it any other way would be greater. Most often the longer lived branches are high cost/risk/reward experiments that may or may not turn out successful. E.g swapping out some component that can’t be done side by side easily (as an example from the real world would be moving from .NET framework to .NET core in a several hundred man-year code base). Most “short” branches I do is 24-48h so typically a half day to a full day of coding then about the same amount of time waiting for reviews and validations.
- j4yav 3y ago

j4yav 3y ago

What’s actually different in the 2024 update?

ABS 3y ago
I posted a note in a comment but was flagged. see https://martinfowler.com/recent-changes.html https://martinfowler.com/recent-changes.html