3 ms·
Continuous Deployment is a very intriguing idea. I haven't tried it, but in the the limit it makes sense. A few years ago I worked for a company that did large
by russell 17y ago
Continuous Deployment is a very intriguing idea. I haven't tried it, but in the the limit it makes sense. A few years ago I worked for a company that did large batch releases, scheduled every 3 months. The first month was spent negotiating with product management over product requirements and writing functional specifications. The next month was writing code. The third month was fairly rigorous QA, so much so that there was usually another month to fix the problems that QA found. The breakdown was 25% design documentation, 25% programming, and 50% fixing bugs that should have been caught in programming. The quality of the code that made it to production was very good, except for one time where a single bug brought the company to its knees for a week.
More recently, I did a consulting gig a company that released every two weeks with a one week QA cycle that allowed for a round of critical bug fixes. This was much smoother. There were rarely any show stoppers and even those were so fresh in eveyone's minds that they were quickly fixed.
Neither place practiced TDD or even rigorous unit testing. Testing was pretty much walking through manual scripts. It seems to me that continuous integration to production requires TDD or something close to it. I also question whether it is appropriate for an application with fiduciary responsibility, but I would love to be convinced otherwise.
- russell 17y agoEDIT: I found a howto page that answers some of my questions and shows hw it works, http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html http://radar.oreilly.com/2009/03/continuous-deployment-5-eas...
- abstractbill 17y agoI don't practice TDD or unit testing, but I deploy code on average more than 5 times every day. Despite not doing TDD or unit testing, I have enough confidence in my code that I spent a month in Greece on honeymoon last year with only a Blackberry, while an average of about 50,000 concurrent users were connected to the chat system I wrote for justin.tv. In that month the system didn't have a single problem. My "secret", if I have one, is that every change I release is very small (maybe 5 or 10 lines of code - 20 lines at the very most). I read and re-read my changes thoroughly before I deploy, and test the new behavior many times. The evolution of the chat system I wrote has been a huge number of very small steps.
- DanielBMarkham 17y agoI'm curious -- were you using a functional language? An OOP language? Something else?
- abstractbill 17y agoPython, because of the twisted library - if I was rewriting, I'd probably use Clojure, but at the time I wrote the system there was no widely-used Lisp with an also widely-used non-blocking i/o library.
- biohacker42 17y agoand test the new behavior many times Manually? You can save a lot of time if automate that.
- abstractbill 17y agoI do have non-unit tests (but only for things that have actually failed more than once). Specifically, I have a bunch of chat bots that periodically log in to the production chat servers, talk to each other, ban each other, etc, etc, and make sure they get the responses they expect. Yes, new functionality I test manually. I believe the time taken to write tests for things that have never failed is wasted.
- axod 17y agoAgreed. Given the choice of logging or unit testing, logging is probably 100x as important in finding and fixing bugs.
- Afton 17y agoI believe the time taken to write tests for things that have never failed is wasted. Yes yes yes. I've seen a lot of tests that, if they failed, would have meant that a thousand other tests would have also failed, and that test would have been simply more noise.