Now that deployment times are recorded on a per-step basis, would it be possible to have the estimated completion time for deployments to be done per-step as well? For example, if deployments normally consist of 10 steps that each take 6 minutes, then it estimates an hour until completion. This, however, doesn’t work well when steps are either skipped or conditional. So if I run only the final step, it estimates 60 minutes instead of 6 minutes. Plus, that deployment then skews completion estimation for other deployments.
TeamCity currently does it on a per-step basis, so that if a single step goes quicker than normal, it re-adjusts the completion time, knowing that the remaining steps normally take X amount of time. Octopus should now be doing the same, since it records everything per-step.
Thanks for getting in touch. The feature where we show a running time is just an additional visual element based on the time stamps in the logs so it wasn’t a lot of effort. There’s a bit more work involved in being able to estimate based on some set of history, say the n last deployments.
Currently estimation of steps and deployments is not something we’re not actively looking at expanding on.
How has your experience been with the reliability of Team City estimates? Or windows file copy estimates? I’ve used Team City for years and we use it here at Octopus, the estimates can be often quite off. They are impacted by strange occurrences in a recent build, e.g. it got stuck on some edge case error or it failed early and fast. When we witness this kind of behavior it influences us to believe that tracking and showing estimates can be of fluctuating value and benefit.
We’re not exactly fans of estimates, but for cases like this we have User Voice to gauge community desire for features we don’t have yet. If you have time, have a look there for existing or feature proposals: https://octopusdeploy.uservoice.com/