This is part of a series. The full list of posts can be found in the introduction.

Validation⌗

Usually, when I delivered this content as a talk, the “Validation” slide came later in the progression. I’m switching it up a little for the blog post series because without proper validation, a lot of hard work can suddenly be all for naught.

** Don’t. Pollute. The. Stream. **

Source control should be a safe place. Bad things are going to happen from time to time, but it should be the exception, not the rule. There are ways to be confident that you’re going to keep things clean and happy for yourself and your team.

Here are a few simple things that you can do before you push (or check-in, or whatever your source control calls putting your changes into a place where they’ll directly affect your team).

I consider this to be the minimum bar of respect and consideration for others on my team, and I feel bad if I realize I skip them^1.

1. Make sure you’re at least syntactically sound (compile, or lint, or what have you)
2. Confirm that the app can actually start running
3. Run whatever tests you have against your changes^2
4. Check status / diff to confirm that only the changes you intend to include are included
   1. Do you have test / debug code that should be reverted?
   2. Do you have local config changes that should be reverted?
   3. Did your tooling do anything ridiculous when you weren’t looking? (cough cough ReDerper^3 cough)

Why?⌗

Because no one wants to pull the latest changes and be blocked by a broken build, or by being unable to start, or by seeing work they did two weeks ago suddenly disappear because you resolved conflicts backwards.

Why not?⌗

Some of the common points of resistance I’ve heard…

1. Not in the habit. Ok, make it habit. Put some form of accountability in place that encourages people to keep things clean. I’ve heard of donating $1 each time you break it, or having to take over deployments until the next time someone breaks it. I’ve heard of dashboards and sirens and traffic lights. I’ve heard of going the other way and creating rewards for those who break it LEAST. Depending on your team culture, there’s a lot you could do here.
2. Too much time. We’ll get to some specific ways to make all of this faster below, but even without those, think about the time you’re going to lose if you just slam code into the repo without paying attention. Time determining which of the recent pushes introduced the problem. Time your coworkers lose unable to build while waiting for it to get fixed. Time chasing bugs that really just come down to a hacky line you put in for local testing and forgot to take out because you didn’t diff.

Making This Easier⌗

Here are some things that I’ve found can reduce some of the friction around validation.

1. Automate all the things. If a task runner is watching your changes and constantly running tests, notifying you if they break, you can fix it before it becomes a bigger problem. gulp watch is your friend!
2. Code review. Looking back over a unified diff helps catch a lot of those “config oops” moments, typos, and weird things that tooling does to “help us” .
3. We’re working on topic branches right now. If I push something awful, only the people working on that topic are affected (at least, that is, until the topic is merged). Note that this doesn’t give us an exemption from validating our changes, but in case we forget…
4. Automate even more things. Michael and I just finished setting up a process for our team that can run various validations whenever new code is pushed to any branch. We also have a dashboard that gives us visibility of the status of each branch at a glance.

What else?⌗

You tell me. I’m sure there are a lot of things we could be doing even better.

–

[1] You should, too.

[2] Be sure you’re running integration/functional tests against an environment that actually, you know, has those changes.

[3] Mostly kidding. ReSharper has some great features. It’s just…sometimes…well, I think it might drink a little is all.