![]() While we can (and should) work to make problem solving and defect fixing systematic and controlled, it will require creativity and innovation, and we can be sure there will be some surprises and things we couldn't predict. It's the "how on earth could this cause that"-factor. \(C_2\) on the other hand is the surprise factor. Ideal for automation, making \(C_0\) as small as possible, and thus \(mC_0\) reasonably small even if \(m\) grows larger. That seems to suggest that small deliveries are better, and that Continuous Delivery becomes more important as your product grows, and get's more changes.īesides, \(C_0\) is about IT processes, which should be standardized, predictable and repetitive. On the other hand, looking at the last term, \(n^2\) means that \(mC_2n^2\) can become the dominating term if \(n\) is large, even if \(C_2\) is small. If \(C_0\) is big, it seems we want to minimize \(m\) and prefer few and big deliveries. Looking at the remaining parts, \(mC_0\) and \(mC_2n^2\), we can make some observations: Of course it's good if \(C_1\) is as small as possible, but that's true whether we make one big mega-delivery, or many, tiny deliveries. For a fixed \(x = mn\), this part will be \(xC_1\) per year either way. If we look at the middle term \(mC_1n\) first, we notice that it doesn't matter for this part of the equation if we make many small deliveries, or fewer but bigger. In this text, I'm focusing on costs of delivery.Ĭall the total cost of a single software delivery \(C_\) for a certain \(x\)? How many deliveries \(m = x/n\) should we make? I've also explained how deploying software in baby steps might reduce risks and downtime, in A Use Case for Continuous Deployment. There are some obvious benefits with frequent deliveries, and particularly with frequent deployment, such as being able to use new features sooner rather than later. How could the former be more efficient than the latter, if each delivery has some setup time etc? If we imagine that we produce \(m\) deliveries each year, with \(n\) changes in each delivery, we'll deliver \(x = mn\) changes in a year regardless of if it's \(x\) deliveries of \(1\) change each, or \(1\) delivery of \(x\) changes each. Quality must be allowed to take time, and since the must let each delivery take a reasonable amount of time, we can't make them too often, so we need to include as many changes as we can in each delivery, right? Of course, it would be great if emergency fixes were as reliable and well tested as ordinary releases-they certainly deserve to be that, but isn't that just a dream?Įach delivery requires a substantial amount of time and resources, so surely making many deliveries, must be more costly than making fewer and bigger deliveries, right? If we rush a delivery, it's likely to turn out broken. You can probably deliver an emergency bug fix fairly rapidly in a pinch, but could you continuously make all your deliveries in that speed without making a mess? Those emergency fixes are special cases, and maybe done in a way which wouldn't be sustainable if all changes were made like that. If normal feature deliveries typically takes days or weeks, it seems impossible to make them every time a programmer checks in some code. "Maybe it works for someone else, but it won't work for us," is a common thought. fairly infrequent, software delivery, the idea of Continuous Delivery will probably seem hopelessly expensive.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |