Using the "( Test && Commit ) || Rollback" ("TCR") approach is and has always been intended to be used with Test-Driven Development (TDD). Writing tests should be an integral part of it.
It was criticized for breaking the Red-Green-Refactor cycle.
So I described how to fix it to reenable Red-Green-Refactor (for TDD, and TCR)
By my calculation, that 40 hour investment in improving the build time that you give as an example above, pays for itself about 17.5 times a year. In other words, it will take less than three weeks for it to pay for itself. That is, in less than a month, that one week of work investment is paid for, and then you get "pure profit" (IE: savings) from then on.
Most of our test suite runs pretty fast (and tests for code we're working on can be run via the REPL too) but some parts of our system interface with external payment systems and even using their sandbox services things can be slow to run, but non-billing changes can cycle from commit to production in about 30 minutes (including rolling deployment across our cluster).
That wasn't always the case. Deployments used to be mostly manual and error-prone and take more than 30 minutes on their own, first to staging for the product team to review and sign off, and then to production. Back then, we pretty much never risked deploying on a Thursday, let alone a Friday.
We spent a lot of time over several years streamlining and automating the process and improving test coverage (we were not test-driven when I first joined) to get where we are now. We developed a feature flag system, baked into the multi-tenant admin app the business team use internally, so features can be turned on and off by them, on a per site basis (across our 40+ sites), sync'd between the backend and the frontend.
Deployments are "no big deal" now and we regularly deploy small features and fixes as soon as they are "ready", doing multiple releases a week (and occasionally multiple releases in a day), and we're no longer afraid of Friday afternoon deployments!
We also have a lot of automated monitoring -- both at the system/software level and at the business level -- so we get early warnings if any release makes something worse instead of better, and either rolling it back or deploying a fix quickly through our build pipeline.
The whole company is a lot happier -- not just the development teams! :)
"If we look at the total cost of the whole year of deployments, including the cost of doing deploys and the cost of holding onto features that are ready but aren’t in customers’ hands, it is proportional to the square root of the deployment cost. So, reducing the cost of deployment will reduce the total cost."
Using the "( Test && Commit ) || Rollback" ("TCR") approach is and has always been intended to be used with Test-Driven Development (TDD). Writing tests should be an integral part of it.
It was criticized for breaking the Red-Green-Refactor cycle.
So I described how to fix it to reenable Red-Green-Refactor (for TDD, and TCR)
https://jeffgrigg.wordpress.com/2018/11/23/test-driven-development-with-test-commit-testcodeonly-revert/
By my calculation, that 40 hour investment in improving the build time that you give as an example above, pays for itself about 17.5 times a year. In other words, it will take less than three weeks for it to pay for itself. That is, in less than a month, that one week of work investment is paid for, and then you get "pure profit" (IE: savings) from then on.
Less Than One Month.
Most of our test suite runs pretty fast (and tests for code we're working on can be run via the REPL too) but some parts of our system interface with external payment systems and even using their sandbox services things can be slow to run, but non-billing changes can cycle from commit to production in about 30 minutes (including rolling deployment across our cluster).
That wasn't always the case. Deployments used to be mostly manual and error-prone and take more than 30 minutes on their own, first to staging for the product team to review and sign off, and then to production. Back then, we pretty much never risked deploying on a Thursday, let alone a Friday.
We spent a lot of time over several years streamlining and automating the process and improving test coverage (we were not test-driven when I first joined) to get where we are now. We developed a feature flag system, baked into the multi-tenant admin app the business team use internally, so features can be turned on and off by them, on a per site basis (across our 40+ sites), sync'd between the backend and the frontend.
Deployments are "no big deal" now and we regularly deploy small features and fixes as soon as they are "ready", doing multiple releases a week (and occasionally multiple releases in a day), and we're no longer afraid of Friday afternoon deployments!
We also have a lot of automated monitoring -- both at the system/software level and at the business level -- so we get early warnings if any release makes something worse instead of better, and either rolling it back or deploying a fix quickly through our build pipeline.
The whole company is a lot happier -- not just the development teams! :)
I got a bit lost in this paragraph:
"If we look at the total cost of the whole year of deployments, including the cost of doing deploys and the cost of holding onto features that are ready but aren’t in customers’ hands, it is proportional to the square root of the deployment cost. So, reducing the cost of deployment will reduce the total cost."
In "it is proportional ..." who is "it"?
The total cost is proportional to the square root of the deployment cost.
Thanks for asking so I can clarify!