Developer Pipeline

Project Managers and Developers alike need something reliable. What if there was a way to provide verification that changes were made?

What’s in a Developer Pipeline?

Build: All code committed is packaged up with all dependencies.
Test: Basic checks are in place to make sure requirements are in place.
Local Deploy: It is then deployed to an internal dev site for all to review.
Compare: The dev site is visually compared against the live site.
Hold for Deploy: Nothing goes live without an actual manual approval, as a sanity check.
Approval: The go-live process is automated, and no one is allowed in to muck with it.

An early simplified edition of the pipeline
Alerts were issued on the visual comparisons.

How were goals achieved?

This was a multi-year process. It all started with finding the common ground of software requirements on the staging server. Even if updating projects on that server was manual for months, each time that manual process was run, another step was added to slowly to and converged upon a consistent set of scripts, able to be automated.

Once the staging server was consistently handling a variety of projects, we started to replicate the setup locally. Vagrant was actually the worst part of the process. Docker is rightly a popular successor.

Finally, the last step was to choose between Jenkins, CircleCI, and other competitors.CircleCIwon out for its independently managed flexibility. The actual spin up of CircleCI was relatively easy. All the hard work was in the overhaul of workflow process.

	Goals	Application
Flexibility	Providing a base platform for every developer to build on locally, or remotely.	Vagrant image provided for local and dev servers; next round will use Docker.
Flexibility	Allowing each developer to use their own coding tools, while agreeing on a few core essentials.	If vagrant is too bulky, developers can run their own platform, so long as their code still passes tests. When using Sublime instead of Atom, be sure to install an equivalent linter.
Consistency	Every step that is automated can be manually replicated for debugging.	All the tools that used in automation are also available to developers on the local virtual machine for manual step-by-step checking.
	Starting from known sources: Each external resource would have a version or release number specified	Using a package manager instead of adding everything to git.
	Keeping content & resources available independently from code.	All uploads were sent to Amazon S3. Local virtual machine has MySQL replicated for fast local reads.
Confidence	Basic tests for easy-to-miss things	Added to CircleCI
	Visual tests to compare what we are about to go-live with vs. what is presently live.	BackstopJSwas added to CircleCI
	Independently stored site versions (code and data) for easy rollback	No live-site deployments are overwritten, just moved.

Takeaway:

Having visual tests automated and readily available has been the biggest confidence builder for our design and management leads. We are able to have a record showing the changes applied.

Sample visual comparison from BackstopJS.
A bad database import resulted in added glyphs.

Importantly, we also reduced a culture of immediacy. No longer was everyone nagging the go-live manager and waiting impatiently playing the “refresh game” as it was nicknamed. Project changes went live when the machines deemed it so.