For enhanced software delivery performance, continuous integration and continuous delivery have proven to be pivotal.
The State of CD Report findings are based on data from the previous six Developer Nation surveys, which reached more than 125,000 respondents worldwide over two and half years. The report is an important resource for organizations to understand how the performance of organizations across different industries is impacted by applying CD practices and using modern technologies while highlighting some of the emerging trends to keep an eye on and pitfalls to avoid.
The second CD Foundation User Story is now available: Developing Complete End-to-End CI/CD Pipelines at Ericsson.
This time around, Ericsson shares how they improved on scalability and observability by introducing a common event protocol in their CI/CD pipelines that sends over 3 million events per day, to benefit their 20K+ developers.
“Ericsson is actively contributing to the Continuous Delivery Foundation through various SIGs and also to the CDEvents project. Ericsson also held an end-user seat in the CDF TOC up until last month. We believe it is important to be involved in this foundation as an end-user to make sure our needs in the CI/CD space are catered for in the various open source projects we are using internally.
“Ericsson took part in creating the CDEvents project and is highly involved in the progression of the CDEvents protocol. This blog post describes Ericsson’s path to an event-driven CI/CD solution.”Emil Bäckmark, CI/CD Architect, Ericsson
Thank you to the authors:
- Kristofer Hallén, Principal Developer, CI Tools Architect
- Emil Bäckmark, CI/CD Architect
- Mattias Linnér, CI/CD System Architect
Ericsson has been very involved in the CD Foundation for many years now, even winning the CDF End User Award in 2022. Emil Bäckmark served on the CDF Technical Oversight Committee as an end user representative between May 2022 and May 2023 and also is the co-chair of the CDEvents project as well as the Events Special Interest Group (SIG).
What are CDF User Stories?
The CDF User Stories Program features real-world use cases from companies embracing the change brought by Continuous Delivery, increasing their ability to deliver software with security and speed. The goal for the stories is to show the impact of adopting Continuous Delivery as a software development practice along with enabling CD technologies, (such as the CDF projects) the steps taken by respective organizations, and the additional benefits these resulted in improving the developer experience and productivity.
It’s a valuable resource for organizations that want to adopt Continuous Delivery and open source technologies because it showcases organizational leaders in their field.
You can read the first user story by Fidelity Investments: Securing Fidelity Investments’ Software Supply Chain.
Share your Story
We have a few stories in our pipeline, but if you’d like to contribute a user story, read the guidelines and send us a proposal!
Questions? Email: firstname.lastname@example.org
Contributed by Justin Abrahms, eBay
Drawing a software delivery pipeline is a task that takes a couple of developers 30 minutes and a whiteboard.
We start our build, we do some testing, try it out in staging and… when we’re happy… publish it to production. Going from there to a working pipeline that’s modeled in the way that you want either requires a large framework investment that’s likely company-specific (Amazon, Google), using a SaaS provider (CloudBees, CircleCI), or writing a bunch of Kubernetes YAML / Bash scripts.
At the Interoperability SIG, we’ve been discussing what it might look like to have a simplified DSL for expressing the outcomes of a pipeline, without getting so tied into the mechanisms of telling the system how to do it. This is an illustrative (but not particularly battle-hardened) example:
meta: # Channel which will get updates on deploys. One message for each release and # Information in the thread as it progresses through the pipeline. slackChannel: myapp-deploys # Who to complain to when this breaks. owners: your-ldap-or-equivalent-group-here build: # Explicitly not setting up a jenkins instance. Framework should do this, if necessary. type: docker # ...or... # command: mvn package deploy: default: # These apply to all stages below, unless they're overridden cores: 100m memory: 300Mb ramp: # deploy to 1% then 10% then 100% as a rollout strategy. There will be # a few options available. rolloutStrategy: ONE_TEN_ALL bakeTime: 5m dev: rollout: regions: dev-west-1a staging: rollout: regions: dev-west-1a prod: rollout: regions: prod-west-1a, prod-west-1b, prod-west-2a, prod-west-2c # Starting from 1, deploy to 2x the regions of the last deploy, so 1,2,4,8,16. strategy: GEOMETRIC approvals: - metricsValidator: promql: sum(increase(failure[5m])) > 5 onResults: rollback
Something like the above would allow us to simplify the expression of what we want the shape of our pipeline to be, but without having to become experts in Tekton or Argo or any of the other great tools for accomplishing this. This will hopefully allow more developers to engage with CI/CD pipelines and have a more active role in the quality of their software.
Join on December 2 to discuss, collaborate, and contribute to SIG Interoperability and the broader CI/CD ecosystem in CDF.