Automating Our Environment Without Changing The Culture
We take our engineering disciplines very seriously, ensuring that we enforce spelling within our source (this has come in hand many, many times) and defining linting format standards. Like many organizations, we control these with pre-commit hooks when checking in changes, and it’s the engineers responsibility to fix before pushing, but some of these can be better handled out of band.
For example, instead of requiring engineers to check for spelling issues locally, we have a job that runs the misspell command against our source code, documentation and other UI components, which fails if there are detected misspellings. Putting on our DevOps hat, we think aloud that instead of having this fail and be forgotten, until the next tech-debt cleanup day, is if we had our CI platform automatically generate a PR for the fix for all processes which had corrective actions.
The following example is from our CI which checks for misspelled comments and strings, and if it fails, it will autocorrect the spelling and then push the branch back to the repo (with some crafty permissions) and submit the PR.OUTPUT=$(find . -name '*.go' | grep -v vendor | xargs misspell -error) || push_prfunction push_pr() {
find . -name '*.go' | grep -v vendor | xargs misspell -error -w
git add .
git commit -m "fixing spelling errors from build $BUILD_ID"
git checkout -b pr/misspell-$BUILD_ID
git push -u origin pr/misspell-$BUILD_IDcurl -XPOST -d '{"title":"'"Fixing misspells for build $BUILD_ID"'", "base":"master", "head":"pr/misspell-$BUILD_ID", "body":"'"Fixing misspells for build $BUILD_ID"'"}' \
https://api.github.com/repos/<org>/<repo>/pulls
exit 1
}
This leaves the engineer who made the commit responsible for the PR which keeps them in control, but allows them to be more agile and happy by decreasing time for code commits and speeding up the delivery pipeline.
We can take this one step further and use it for gofmt, rubocop, etc.
Conclusion
Keeping good software engineering practices at the forefront of the delivery pipeline is every engineering leaders dream. However, there is more to it than just writing a policy and taking points off a performance review for failing to comply. Setting the example and leading from the front is what great leaders will do to make calm out of chaos.
With some good ‘ol DevOps intuition in our back pocket, we don’t fret and make the environment stressful. No! We wipe our brows and think about how a great engineering team with effective leadership turns these quarrels into conquerable challenges.
In general, for us the challenge was not “how do we lay the tracks to get to our destination?”, but “how do we build the engineers who will build the trains that will take us there?”.
Our answer came with the swiftness of a train traveling at full-steam ahead: solve the problem through automation, but keep the engineers in control.
Laying the tracks is the easy part, it’s making the tracks useful that open up the real challenges.
Member discussion