The journey to realizing DevOps in any organization is fraught with a number of obstacles for developers and other stakeholders. These challenges are often caused by key CI/CD practices being misunderstood, partially implemented or even completely skipped. Now, as the industry positions itself to build on DevOps practices with a Software Delivery Management strategy, it’s more important than ever that we implement CI/CD best practices, and prepare for the future.
Join host Mitchell Ashely, and CloudBees’ Brian Dawson, DevOps evangelist, and Doug Tidwell, technical marketing director, as they explore and review the CI/CD best practices which serve as your stepping stones to DevOps and a successful Software Delivery Management strategy.
The webinar will cover CI/CD best practices including:
Containers and environment management
Continuous delivery or deployment
Movement from Dev to Ops
By the end of the webinar, you’ll understand the key steps for implementing CI/CD and powering your journey to DevOps and beyond.
6. We still have...
● Disparate, stand-alone software tools
● No common language, data or process sets
● No clear way to ensure we deliver the right thing
Disconnected and Fragmented teams, tools and process
This text is from the webinar registration page at https://webinars.devops.com/ci/cd-best-practices-for-your-devops-journey.
I left a few slides from the SDM deck in here. I’m sure we don’t need all of them, but wasn’t sure how much you want to talk about SDM here.
Liked the background on this slide and the next one, left it in here
Brian
Brian
Doug
Must Integrated to SCM, create a Bill of Materials, which is required
Containers, pipeline as code, Confirg as code
Allows you to observe
Doug
I did the rest of the slides in this format. It doesn’t take long to cut and paste the text into the bullet point style if you want to go that way.
Brian: Do make note to the fact DVCS is Git, is the new way. But as you look to connect all teams you may have to build in support for a SVN style work flow
Cover pull requests
This is table stakes for continuous integration. A developer can set up an automated build and have the build run on every commit. But if the culture is to not commit frequently, it won’t matter. If a developer waits three weeks to commit or branches off for three weeks, he has delayed the integration and broken the principles. If a build breaks, the team has to sort through three weeks of work to figure out where it broke.
Principle is integrate changes early and often to find and fix problems fast, so the cost of fixing issues is less, or even more importantly errors dont make it to production
Do: Use solution like Multibranch plugin (Jenkins) or preview environment (Jenkins X) to trigger build on Pull Request
NEED TO ADD TIPS ON HOW TO KEEP THE BUILDS SHORTER. But make sure they don’t contradict what we say in the Validate and Test section.