Editorial Hi Clojurists,
We don't know how lucky we have it as developers today. There are stories on the internet about a phase of development called "integration". What happened was after planning, there was development. And after development, you would spend a huge amount of time integrating everybody's work together for the first time.
Integration would take months. Sometimes it would take longer than development. Engineers considered integration to be so painful that they would put it off till the last possible moment. Some thoughtful people realized that the longer they waited, the harder the integration would be. So they advocated doing the painful thing more often. By doing it often, developers were forced to communicate sooner and more frequently. Integration fixes became small.
Then Extreme Programming (XP) came along, with its idea of "If something is good to do often, do it all the time". So XP advocated for integration several times per day. The extreme ideal would be to integrate continuously: every keystroke that resulted in a good build would go straight to the master branch. This is still impractical, but tooling gets us close (once every commit). Git came along with much faster merging and improved diffing. Automated testing has come a long way. And Continuous Integration servers, both open source and hosted services, are easy to set up.
CircleCI asked me to write an issue exploring the workflows, practices, and tools that help achieve continuous integration. Continuous Integration is more than a service. It's a practice that aims to make a release candidate on each commit. That means that some discipline with branching, merging, and testing is important.
Please enjoy the issue and thank my sponsor, CircleCI.
Eric Normand <email@example.com> @ericnormand
PS Please tell your friends about the Gazette! It's a great way to show support.
PPS Learn more about the Clojure Gazette and subscribe. Learn about advertising in the Gazette.