4 ms·
commit and deploy often and rollback if something messes up This describes pretty well what we do at Justin.TV too. These days I push new code about 5 times a
by abstractbill 18y ago
commit and deploy often and rollback if something messes up
This describes pretty well what we do at Justin.TV too. These days I push new code about 5 times a day.
- emmett 18y agoAlthough to be fair, we don't have that totally sweet "immune system" thing. I have to admit, it sounds pretty cool.
- TimothyFitz 18y agoI've read your post on unit tests, and I didn't understand what you were trying to say. Were you saying don't write automated tests that test your code, instead focus on monitoring the actual production invironment? Or were you saying that specifically the "unit test" class of automated tests are not worth their time? I can imagine a system that monitors the business metrics well enough to prevent defects from slipping into production (it's a stretch, metrics are soft and squishy moving targets), but I can't imagine using only those metrics to find every bug you ever slip into production. Metrics are so distant from the bug that caused their downturn; you'd waste so many cycles debugging. The gap between writing the code and finding the problem would be much larger than if unit tests found them; that has to slow things down as well.
- abstractbill 18y agoHere's where we are putting our effort: - Monitoring the production environment, tons of effort. We record and analyze an incredible amount of data about everything that happens on the site, and have more and more automated processes looking for anomalies (though still nowhere near as many as I would like). - Automated testing not including unit tests, some effort. I wouldn't be opposed to us doing more of this, but it's not incredibly high-priority and there always seems to be something else that's more important. - Unit testing, yeah, not worth our time as far as I'm concerned.