By Steve Persch January 24, 2017
Martin Fowler's definitive post on Continuous Integration gives many specific guidelines for teams using build processes to compile, test, and deploy their source code into the complete final product. Those guidelines include "Keep the Build Fast," "Test in a Clone of the Production Environment," and "Fix Broken Builds Immediately." Among the many guidelines is an easily overlooked nugget of wisdom that can guide teams developing their CI processes. Fowler says "Continuous Integration is all about communication."
Drupal and WordPress developers constructing their CI pipelines face an overwhelming number of questions. How and when do we download dependencies? What is our mechanism for compiling frontend assets? Should we use a hosted CI service? Which one? With each topic, you should ask questions about technical merits, such as speed and extensibility, and most critically, ask how your team's communication could improve.
Implementing Continuous Integration: Where to Start
Knowing that communication is the essence of Continuous Integration will help you prioritize work. Imagine a team that has two pain points that could be solved through fully automated scripts. First, everyone on the team is compiling Sass in slightly different ways. Some people have their own Grunt files, some run LibSass directly. The inconsistent tooling leads to bugs. The second problem is that each developer has to manually spin up a testing server to show their branch to the client for review. Everyone knows how to do it, but it is time consuming, annoying, and could be fully automated.
If Continuous Integration is all about communication, this team should address their Sass compilation before fully automating deployments. Focus on the problems that cause confusion and inefficiency before the problems that are only inefficient. Codifying the Sass compilation process into a build pipeline is a byproduct of the conversation had by the team about resolving the confusion. In this way, Continuous Integration processes encourage conversation, but should not be thought of as a replacement for it.
Using CI to Onboard Team Members to New Projects
I have heard some teams get excited about build processes as a replacement for onboarding conversations. Once everything is scripted, new team members can be brought onto a project without spending a day talking to an existing team member about local environment configuration and gotchas, right? Well, maybe.
Yes, a new team member should be able to clone the code, run a command, and have a working local build. That working build is then a starting point for the conversation with the existing team. Instead of spending hours talking about where to download database backups, setting up symlinks, and updating plugins, the conversation can be about the needs of your client.
Continuous Integration for Agency Teams
Continuous Integration can also help teams of teams. Most web development agencies have numerous client projects moving at once. Sharing best practices among the overlapping team members crossing those projects is a never-ending challenge. Even the best intentioned agencies can end up relying on oral tradition as their de facto knowledge sharing mechanism.
A culture of Continuous Integration encourages everyone to write down their practices. Write them so specifically that a computer can execute them. It is much easier for advances made for client project to be shared with another when those advances are written as scripts.
Your Future Self Will Thank You
From large agency dev teams down to even the agency of one—AKA: the freelancer—Continuous Integration helps coordinate with your future self. Clients have a habit of coming back months after major project work was completed and asking for a quick bug fix or new feature. A developer who scripted their local environment project configuration and deployment pipeline will be able to meet these requests much faster.
To learn more about Continuous Integration and see how a mature build process helps a real agency, check out my webinar with Last Call Media. We look at CI in the abstract and walk through Last Call's real build processes that tie together external repositories, CI servers, and Pantheon Multidev environments.
 |
Continuous Workflows 101 |
You may also like:
-
Why Version Control? Collaboration, Accountability, Security [BLOG]
-
Continuous Integration, Delivery, and Deployment: Behind the Hype [BLOG]
-
How Kalamuna Uses Automation to Liberate Developers & Empower Newbies [CASE STUDY]
