This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• chore(deps): update dependency hugo-extended to v0.132.2
• chore(deps): update peaceiris/actions-hugo action to v3
• 🔐 Create all pending approval PRs at once 🔐

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

From Dave Farley:

I would add the idea that a pipeline "should be definitive for release”.

If the pipeline says everything looks good, that should be enough - it forces the focus on what “releasable” means.

Change "The application pipeline is the only path to deploy to production."
to "The application pipeline is the only path to deploy to any environment."

It should be made clear that only the pipeline is used for any destination.

footer for new site is not displaying correctly

I saw an issue with the following sentence grammer.
https://minimumcd.org/minimumcd/ci/#recommended-practices
"It can also let you recolt metrics on how good the feature behaves performance-wise before make it accessible."

I couldn't figure out what 'recolt' meant. Looked it up. The sentence will read better as follows:
It can also let you review metrics on how well the feature behaves performance-wise before making it accessible.

Mike Nygard was questioning this practice. When I clarified that it meant that the only path to production was the pipeline and not that there was only one pipeline for the entire organization, he was happier. Suggest we change it to "The pipeline is the only path to production"

In some way, for beginner people and organizzation that come from a non agile practice /mindset, is not clear that working in small batches, (using for example user stories) is a foundation practice to get CD work.

This is also the first way of DevOps : system Thinking and flow:
without working in small batches we can't have flow, and we can't have the fully advantages of Continuous Delivery.

This misunderstanding, is something I was on, when I started our devOps / CD transformation, and is something that I still struggle to make my colleagues understand.

If there is room for it, I would be interested in contributing a minimum viable Brazilian Portuguese translation of the manifesto.

I understand that there is already a Portuguese translation, but Brazilian Portuguese has orthographic and grammatical differences.

Thanks for the synthesis and for providing us a solid ground for further discussion of the topic.

Is your proposed change related to a problem? Please describe.
In the "Signatories" list, every link seems to be broken because of the closing parenthesis for every contact. It adds a "%29" in the associated link.
You can see it if you compare for example "Dave Farley" 's link in "Contributors" and in "Signatories":
"https://www.linkedin.com/in/dave-farley-a67927" for the first link, "https://www.linkedin.com/in/dave-farley-a67927%29" for the second. The first one will open the associated Linkedin profile whereas the second link won't.

Describe the solution you'd like
Remove the ")" for all "contact" keys in the signature.yml file

I get the following error message:

failed to extract shortcode: shortcode "children" must be closed or self-closed

Is your proposed change related to a problem? Please describe.¹

It keeps bothering me to see my pull request for signature (#259) merged despite the failed GitHub Actions workflow result. It now has a big red cross next to it in the list of commits and pull requests which might not be easily fixed retrospectively (or at all) :(

My understanding is the test failure was unrelated to the PR, and a conscious choice was made to deploy an updated list of signatories.

Still, I consider it important to demonstrate the listed practices are also applied in this repo, given:

• the spirit of the manifesto itself (for example "All feature work stops when the build is red")
• funnily one of the broken tests is about the "TEST!" section
• especially now that my signature is already deployed to the page (thanks!) :)

Describe the solution you'd like

Test suite should pass, so at least fix the current failures – which I already did, and I will send as a PR soon! :)

Ideally, in the future, broken builds would be fixed before continuing with other work.

Describe alternatives you've considered

1. Review branch protection rules in this repository

   Indicating which tests must pass in order to consider a PR mergeable could help enforcing the desired policy more closely. It might also help communicating expectations towards contributors through better automated feedback.

2. Update the tests to more completely reflect the expected state of the repository.

   Project maintainers might have much more complete insights about the intended quality gates.

3. <fun>Can't fail a test if there are no tests, so disable them 🙃 </fun>

4. Open one or more discussion topics about the details.

   I found it is faster for me to fix the tests this time. Parts of the text may be split out into separate issues/discussion from here as desired.

I'm wondering if we are missing a broader scope of the principle of "version control everything." (maybe its mostly missing with respect to infrastructure). I know it is covered slightly in application config deploys with artifact, but especially with modern applications being deployed to modern platforms with woefully out of date practices, (especially with respect to cloud infrastructure) I'm wondering if there is a tie in here. It may also be that something more needs to go into the application config section (app config plus infrastructure?). Can you be confident in all changes to your app as the infrastructure changes beneath you?

Sorry if I'm late to the party.

Hi,

I wonder if there is a redundancy in the descriptions of Continuous Delivery and Continuous Integration on the main page. As defined there, CD encompasses CI. CI requires that "all feature work stops when the build is red". Then, CD requires "Use Continuous Integration" and that "all feature works stops when the pipeline is red".

If red build and red pipeline are distinguished here on purpose, there should be a definition of what comprises a "build" (e.g., are automatic tests part of this?). If there is no meaningful distinction, I suggest we drop it from the CD definition, as it is already included by requiring CI.

Best regards,

Michael

Istvan Bathazi's linkedin profile appears unavailable when i open it

Is your proposed change related to a problem? Please describe.
I feel a criteria is missing.

If a pipeline is non-deterministic (so the same inputs don't reliably lead to the same output, i.e. the pipeline is flaky), it puts the trustworthiness of the entire pipeline and indeed the process in jeopardy.
It also undermines the power of one of the present demands: "All feature work stops when the pipeline is red". If the pipeline can go red spuriously, people will stop caring and develop alarm blindness (at best).

Describe the solution you'd like
For this reason, I propose the inclusion of this new MinimumCD criteria.

Describe alternatives you've considered
One alternative would be to simply not include it, as keeping the manifesto brief is of great value.

Problem
The Portuguese translation is slightly outdated

Solution
A Brazilian translators that so happens to live in the UK may volunteer to update it.

Describe alternatives you've considered
Another good soul may do the same :).

Here is an item for consideration.

What about changing
Work has automated testing before merge to trunk
to
Work has automated testing before merge to trunk and does not merge if test failures exist
?

I want to understand you signatories thoughts on something I am calling "quasi-acceptance tests".

Let me describe a scenario: I work in a company where a few bugs in production from time to time is not a big problem because:

• We revert fast.
• State corruption is not a problem because almost all data are recoverable by the systems themselves (self-healing), except a few dozens. Those few dozens without self healing rely on backups we perform periodically on our databases.

Tests are critical to us to provide fast feedback on our changes. However, we don't write Acceptance Tests in the original definition that they run on production-like environments. I think we can agree these tests are just costlier and slower than others that evaluate the system running locally on the developer machine or the deployment pipeline runner.

I still find acceptance tests useful for

• self documenting the system
• using ATDD to make sure we spot our wrong assumptions about what the code should do early in the development process
• testing functionality as a whole instead of pieces of code

I am calling the tests I am writing "quasi-acceptance" tests because they are written almost as business criteria acceptance tests, in the sense that they describe the business functionalities the code is implementing. They are not acceptance tests because they don't run in production-like environments. The advantage is that they run very fast, just like small tests, allowing us to run them on commit stage.

I want to known and understand the signatories thoughts and opinions about these "quasi-acceptance" tests. Can you help me scrutinize this, please?

Proposal : French translation

I propose to translate the manifesto in french to contribute and diffuse it in french communities.

What do you think about it? Useless? Useful? Any impediments?

Thanks for reading ❤️

To improve the overall UX and discoverability of supporting material, I propose refactoring from the default GH Jekyll to Hugo.

• We can also decouple the physical MVP items from the signatures while still displaying both on the main page.
  • Improves traceability of changes to core principles for ourselves and others
• We can also create a menu of sub-pages with search.

Most people I know do not define TBD as being equal to feature branching (even if 'short-lived'), but this is your assertion.

IME TBD is where people develop on trunk, not on a branch. This is quite different from feature branching, no matter how short-lived, and requires a different workflow. PR reviews are, obviously, impossible with TBD. Pairing, TIP, AAR and other mechanisms are necessary instead.

Actual TBD seems to be described, almost as an afterthought, here: https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/

I've worked on a couple of 'commit straight to trunk' teams before, they were, on the whole, great experiences. "5/5, would do this again".

My suggestion is you consider 'not to settle' for feature branching and instead promote committing-straight-to-trunk as the TBD to aspire towards.

I propose adding definitions for "deploy" and "release" as tasks in the context of software development.

The manifesto is clear on the necessity of defining "deployable" and "releasable" inside an org, but the separation between the 2 actions is not clearly defined. One could assume that "deploy" means "moving into production" and "release" means "making it available for others", specially when one is not a native English speaker.

Dave Farley offers an answer here: https://www.davefarley.net/?p=333

It could serve as a starting point, maybe?

This proposal is based on the following point:

All feature work stops when the pipeline is red

Is your proposed change related to a problem? Please describe.
I disagree that all feature work must stop in these contexts. Particularly on a team where multiple people are working on features on the same product. I don't believe it is not be reasonable to suggest that all feature work must stop until the pipeline is green. It is, however, reasonable to suggest that the pipeline must be green to merge a feature.

Describe the solution you'd like
I propose the following verbiage:

Feature work is not merged when the pipeline is red

Describe alternatives you've considered
I have considered that some teams may be of such a structure that would make stopping feature work for a red pipeline a necessity. Otherwise considered alternative verbiage stating the same as my proposed verbiage.

Is your proposed change related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I don't agree with[...]
=> Working in small batches is described as a necessary condition to continuous integration and trunk-based development in DORA research and Accelerate (see https://cloud.google.com/architecture/devops/devops-process-working-in-small-batches)

Describe the solution you'd like
A clear and concise description of what you want to happen.
=> Add an item "Working in small batches" in the list of minimum activities for CI
=> Eventually add it also for the list of minimum activities for CD

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
=> Mention the importance of working in small batches in the introductory text

Is your proposed change related to a problem? Please describe.
This is just an enhancement, there's currently a draft page called "Test==Prod" that needs content.

Describe the solution you'd like
I've drafted some content for this page, including "Definitions" and "What is Improved". For the initial pass, I'm including info on staging and ephemeral environments.

Describe alternatives you've considered
N/A

👋

I am curious if the minimums around CD should include language to differentiate delivery and deployment.

As an aspiring CI/CD practitioner, I've chosen to use a separate pipeline to help manage the flow of application code & config from the deployment code & config. Much of my experience is in large environments with many cross-team dependencies in the services space resulting in congruent constraints:

• Application code being trunk based development shouldn't care about deployment
• Business-aligned deployment doesn't map well to a pipeline - in terminology
• The separate deployment pipeline is still rooted in the same principles and practices of the application pipeline

The way I've chosen to describe this separate deployment pipeline is through a different deployment repo - a repo that addresses environment concerns, deployment strategies, and what (from the application pipeline) needs to be where (using releases).

There are plenty of pros and cons to any approach. I'm raising this issue up to see if there's an opportunity for a discussion from other others in the industry.

Thanks!

If :

• "Work is tested with other work automatically on merge"
• "All feature work stops when the build is red"

Don't we have, as a consequence, that "New work does not break delivered work" ?

I'm trying to understand what this last requirement adds to the definition, it seems redundant to me. Am I missing something ?

Thanks !

https://statropy.com/blog/hugo-shortcode-github-button/

Wonderful project! Thank you all guys!

Regarding evolutionary development techniques, I'm seeing that "branch by abstraction" and "feature flags" are present in different places of the website, but not "dark launching"...

Is there a reason for that?

Hi folks,

I've been reading through the website and noticed the text beside the logo in the header looks a bit low. I've added a red horizontal line to show the baseline:

Did you want "MinimumCD.org" to be aligned like it used to be about a year ago in June 2022 (below), and would you want a PR if you don't fix it yourself quickly? I had a look on the Wayback Machine on archive.org to see what was intended.

All the best,
Sean

Some first issues noticed on the French translation of the manifesto

1. the French translation should be revised so as not to confuse "continuous delivery" with "continuous deployment".
   Currently, "Continuous Delivery" has been translated "Déploiement Continu", which means "Continuous Deployment".
   see for instance this page in French from Atlassian: https://www.atlassian.com/fr/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
2. Other terms can also be reviewed : "délivrabilité" => "livraison".
3. The English technical term "pipeline" can be used and not translated by "tunnel".
   Hope it helps,

Discussed in #199

What if i change my mind question is not matching the rest of the questions style

When a PR's pipeline is completed, a deploy preview link is provided (e.g. https://deploy-preview-203--minimumcd.netlify.app/, for PR #203).

However the referred link redirects to the production site (https://minimumcd.org/minimumcd/), not giving the possibility to explore the changes in the produced artifact.

Current trunk branch is master. Propose updating to main

This is just a question, but:

I feel that for a CD pipeline to work, the most important automated test is "does production work" , and it is also the one most often left to humans. There are many ways to solve this, but i think the minimum is either a basic smoketest, or a continuous test that monitors features in production actively.

I'm trying to fix the broken links to the intalian faq.md subsection in the italian readme.bd, but seem that I'm not able to find the correct path.
I've tried twice with differenth paths, but both does not work.
could some one help me please?
Thank you in advance

"improtant", instead of "important"

I'm a bit uncertain what "rollback on-demand" means and not finding a definitive source for what qualifies.

Do these examples qualify:

1. a rollback initiated by a revert commit which progresses through the pipeline
2. re-instating an artifact which previously passed the pipeline
3. a blue-green(ish) deployment where you can point traffic back to the previous version which has not been tore down

A clarification or explanation linked from the main page would be great.

Thanks for your work!

How does one request access to the Slack workspace ( https://minimumcd.slack.com/ )? Are there restrictions on who can join?