A common mistake is to only deploy completed features. It is far better to deploy something as soon as the pipeline certifies a change will not break the end-user. This could be as small as some tested code that won’t be used until several other small changes are delivered. (View Highlight)
a primary purpose of CD is production support. When production has an incident or we have a new zero-day vulnerability, they do want changes that frequently to resolve those problems. (View Highlight)
“Following our principle of working in small batches and building quality in, high-performing teams keep branches short-lived (less than one day’s work) and integrate them into trunk/master frequently. (View Highlight)
Each change triggers a build process that includes running unit tests. If any part of this process fails, developers fix it immediately.” (View Highlight)
How small is small? One change a day is big. Smaller than that. These are not feature complete changes. They are small, tested changes that can be delivered to production if certified by the pipeline. (View Highlight)
“Story sizes should average as close to one day as possible. If they don’t, your Agile project is going to be harder for nearly everyone involved. If your average is significantly greater than that one day, then change something until you get there.” (View Highlight)
