PIVOT!

I don’t use this much.

But I pay for hosting and run for daily backups. It seems like a waste. In typical tech fashion, it’s time for a PIVOT so I can MAXIMIZE MARKET SHARE AND INCREASE PROFITABILITY.

I was able to test how good my backups were today by standing this site back up from exports. I’ve moved hosts to save money and support a smaller hosting provider (AWS to DigitalOcean). I’m happy to say that my previously untested backup scripts worked wonderfully. I was able to reinstall LAMP, drop in the DB and WP files and the site came up on the first attempt.

Going forward, I’ll probably just post more content here that include topics outside of release engineering. I’ve got some cool RE/DevOps type things to post that I’ve been sitting on for awhile. I’ll try to get around to documenting that work and slip it in between ramblings about ethics (my current obsession), new projects, cycling, and just generally revamping this site.

 

Minor Updates

  1. Working on cleaning up KillAllBindings a little. I’ve made some (probably) final changes that I need to test out. Once that’s done, I’m not certain what else I’ll be doing to/with it unless a bug comes up or there’s a need for functionality to be extended.
  2. I’m continuing progress to extending the testing quality of development builds internally while trying to address build speed concerns. Recently I optimized our build process and got build time cut by about 30%. We’re looking at other ways to speed this up all while performing more testing during the build process (which may offset the optimizations, but I’m cool with that).
  3. I’ve started working on a tool that will make source code collection for backing up source easier. It’s called ARC (Archive Released Code) and more information will come as I get closer to completion.
 

Process Enhancements

For a while now, we’ve required code reviews for all changes before they could be merged into a team’s trunk fork. This helped catch some obvious stuff and helped increase code quality. This stuff seems obvious but when it’s not part of the culture, it seems like a big feat.

The next step was to require the code to build before it could be merged. We implemented this about a month ago and so far it’s been a pretty smooth transition. Bamboo picks up the branches (annoyingly, it will build a newly created branch even if there are no commits but that’s another matter), build all of the solutions, and report the status to Stash. If the build fails, the pull request can’t be merged. Progress.

Next, we need to implement unit tests. One team has gotten that working in their fork so it’s just a matter of time to get the changes merged.

This is all text book stuff and it’s been neglected for a while, but it’s good to see us begin to enhance our process. It means more work for me, but it also means that there are less firedrills because less issues will slip through the cracks and into customers hands. I came from QA and I know what it’s like to be in the room with a pissed off manager, pissed off support agent, and a pissed off customer and it feels like it’s all your fault because you missed something.