minimum-cd / cd-manifesto Goto Github PK
View Code? Open in Web Editor NEWMinimum Viable Continuous Delivery
License: MIT License
Minimum Viable Continuous Delivery
License: MIT License
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These branches will be created by Renovate only once you click their checkbox below.
Warning
Renovate failed to look up the following dependencies: Could not determine new digest for update (go package github.com/FortAwesome/Font-Awesome)
.
Files affected: go.mod
.github/workflows/ci.yml
actions/checkout v4
peaceiris/actions-hugo v2
actions/setup-node v4
actions/upload-artifact v4
go.mod
go 1.22.1
github.com/FortAwesome/Font-Awesome v0.0.0-20240402185447-c0f460dca7f7@c0f460dca7f7
github.com/google/docsy v0.10.0
github.com/twbs/bootstrap v5.3.3+incompatible
package.json
autoprefixer ^10.4.20
hugo-extended 0.131.0
husky ^9.1.4
linkinator ^6.1.1
markdownlint-cli ^0.41.0
postcss-cli ^11.0.0
prettier ^3.3.3
prettier-plugin-go-template ^0.0.15
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.
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.1
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:
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
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.
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.
<fun>Can't fail a test if there are no tests, so disable them 🙃 </fun>
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.
edited for conciseness and readability ↩
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:
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
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?
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.
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:
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 :
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 !
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
Originally posted by rlabercrombie April 15, 2022
Given the latest presentation at devnexus (great job by the way!) there were a few questions about 'how to get there' with tough architectures; in this example they mentioned having to have a many year long process of transitioning from VMs to x/y/z prior to being able to achieve (or it sounded like even start) minimal cd.
Would there be any interest in creating a new section or adding to existing sections for use-cases fitting the bill of 'getting to a minimum viable cd system: best practices (or examples... whichever would fit best)?
As an example of a use-case: You have a monolith with zero testing coverage. Separating out a small chunk of code - ideally on an appropriate domain/business seam - into its own project, adding some unit (or other) tests and getting a basic pipeline working as a way of an iterative process? Then you could have parallel work on improving that pipeline and pulling off another small chunk of code.
Or is this out of scope?
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
I'm a bit uncertain what "rollback on-demand" means and not finding a definitive source for what qualifies.
Do these examples qualify:
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.