Continuous Stuff

In a previous post, I talked about automating tasks to save time. Now I want to talk about a particular type of automation that I'm particularly geeked about at the moment: Continuous Stuff (my term, no one else's that I know of - there's probably a more technical term for it, but I don't know what it is). I will note that everything here is lifted from another article I read about a year ago and have been unable to find again and an Interview on the Developer Tea podcast, which I'll reference at the end. There are good articles about Continuous Stuff all over the place, so if you want to find out more about what it is, good practices, or good tools just search around. I would recommend searching for "Continuous Integration", "Continuous Delivery", and/or "Continuous Deployment". There are three levels of Continuous Stuff that I'll acknowledge for the purposes of this post: Continuous Integration Continuous Delivery Continuous Deployment At the Continuous Integration level, your team uses source control and whenever something is checked in, the project is rebuilt and maybe some automated testing is done so that you know your product is always at least in a minimally usable state. And if you're the person who checked in the code, you know when you missed something and need to correct it. At the Continuous Delivery level, the code is regularly being rebuilt, either on a schedule or whenever something is checked in, or some hybrid thereof, then a full set of automated tests are run, so that you always have a shippable product on hand whenever your company is ready for it. At the Continuous Deployment level, whenever something is checked in, it gets build, fully tested, maybe someone signs off on it being deployed, and it gets pushed right into production! That last level, to me as a developer, seems magical. Considering the possibility of making a change and in just a matter of minutes (or hours depending on the testing structure and size of the application), someone can be using the value I've added is simply thrilling, and taking more steps out of the chain between me thinking something and that something affecting the world makes me feel all the much more like a wizard (which is really the whole reason anyone becomes a software developer - because it makes you feel like a wizard, amiright?). It seems to me the trick to getting to this point is that automated testing. You really want full test converage. That is, you want it so that when this is pushed out, it doesn't result in people getting upset because something that worked before is now broken. As someone for whom part of their job is testing to make sure people's changes haven't broken anything, and as someone who doesn't particularly enjoy that part of their job, I also find the prospect of having the computer run through things very appealing. Also, as someone who deals with users when things break, I find the prospect of ensuring nothing does break even more appealing. In the same vein as having complete test converage, it's also important to have well-maintained test converage. By that, I mean if something does fail, you do not ignore it. It's tempting to look at the test and say "well, that test is only failing because it was built when we were doing things the old way and it's only accounting for the old way of doing things. Lets just ignore it." This causes two problems: 1. It makes that test useless and whatever you had previously been testing for no longer covered. 2. It breaks the integrity of your system, making it untrustworthy. And if you can't trust your tools, it's easy to wander into shoddy workmanship. There is one thing to note, regarding complete test coverage: I don't believe it exists. Unless your product is trivial, you can't account for every use case. So what can you do to minimize your users experiencing problems with new releases? One good method is to try out the change on a small number of users at first, then if it goes well with them, roll it out to the rest. This could be a dedicated group of beta users who sign up for it in exchange for some perk you provide, such as a discount or just the opportunity to use new features that aren't available to anyone else. Or you can just pick random people to try it out on. Both methods have their pros and cons, but I'm out of time for writing this, so I'll leave it to you to consider what those might be. References to Developer Tea Interview, as I referenced to earlier: https://developertea.simplecast.fm/cc85e253 - Developer Tea - Russ Taylor Interview - Part 1 https://developertea.simplecast.fm/6ea4da7b - Developer Tea - Russ Taylor Interview - Part 2