How CI/CD works: why releasing code every day is safer than once a month
Integration hell: why weeks of separate work break on merge day
Three developers spend a month on three parts of one app, and each part works. On merge day, the app breaks, and fixing it takes longer than writing the parts did. Software teams have a name for this: integration hell.
-
1
You have just joined Miva and Rono, two developers who build a laundry app. Neighbours in big buildings open it on their phone, book a washing machine, and get a message when the wash is done.
-
2
The team keeps its code in Git, a program that stores every version of it. For a month, each of you works alone on your own branch, your own copy of the code in Git: Miva on a waiting list, Rono on paying by phone, you on a new booking screen.
-
3
On Friday, you merge the three branches into main, the shared version of the app that everyone builds on. Git puts the three lines of work together without a single complaint.
-
4
Then the app gives machine 3 to two neighbours at once. Rono changed how a booking is saved, and Miva's waiting list still reads bookings the old way. Each change worked alone, and together they break.
-
5
Worse, a month of work holds hundreds of changes, and any of them could be the cause. Each time you fix one bug, a new one shows up. Developers call this integration hell.
-
6
On Sunday night, Rono copies the new version by hand onto production, the servers that the neighbours really use. This is called deploying, and this time it came two days late.
-
Go further
The words behind merge day.