Any recommendations for building a CI/CD pipeline in an org that’s never delivered software this way? What’s the best way to get the entire team on board with the new process?
Sort by:
It depends on the kind of software. In the case of Cloud Native software I suggest focusing on Platform Engineering and not just con CI/CD.
The cloud software lifecycle is complex and you need to orchestrate a lot of technologies (see https://landscape.cncf.io/, section Continuous Integration & Delivery).
If you abstract that complexity it's much more easy to implement and onboard on CI/CD the team.
See also that article https://tag-app-delivery.cncf.io/blog/proposal-platform-engineering-/
As usual, start small and gradually increase the rollout once there is more buy-in over time.
Here are the high-level steps that I'd recommend:
- Have a CI hooked into the code repository that runs for every code commit (at least to the main stable branch).
- The CI should produce artifact(s) that can be used for the current deployment process.
- Invest in implementing automated deployment capability with no human intervention.
- When the automated deployment capability is ready, then hook it to your CI/CD pipeline to deploy to various environments.
- Forbid manual deployment. Every deployment must go through the CI/CD pipeline.
While doing the above, also don't forget to invest in quality gates, e.g. automated test, static code analysis, etc.
Reach out if you want some more in-depth conversation!
I've done this at small and large scales and it's often more complex than people consider. This is just as much about organizational support and team support as it is raw technology.
You'll need to ensure business practices are supportive and be ready to adjust most aspects of your SDLC.
The absolute first step is to ensure you can explain what CI/CD really means (what is the objective and end state), then you'll need to be able to explain why those changes are needed. It can be a massive change management effort (check out Kotters 8-step method for change management)
Once you can explain what is expected and why, you can see who's on board and supportive and where resistance will form early.
Move slow and ensure you're not jumping in too far to start.
e.g. Don't force the team to deploy to production with every change until you have discussed concepts like feature flagging, and 'testing in production'
Building a CI/CD pipeline in an organization new to this approach is exciting but requires careful planning and communication. Here are some key recommendations:
1. Start small, but solid: Begin with a pilot project rather than trying to implement across the board. This will help you work out any kinks and gather valuable feedback before scaling up.
2. Automate testing early: One of the most important aspects of CI/CD is automation, particularly in testing. Integrate automated testing as early in the process as possible to catch bugs quickly and ensure a smooth pipeline.
3. Choose the right tools: Pick tools that suit your team’s existing skills. Jenkins, GitLab CI, CircleCI, and Azure DevOps are popular options. Ensure the tools integrate well with your existing environment (version control, container management, etc.).
4. Training and upskilling: Bring the team up to speed with workshops, hands-on training, and demos. Make sure there’s a clear understanding of version control (Git), containerization (like Docker), and the overall CI/CD flow.
5. Foster a culture of collaboration: CI/CD is as much about culture as it is about tools. Encourage open communication, embrace failures as learning opportunities, and emphasize that continuous improvement is the goal.
6. Gradual implementation: Introduce changes gradually. First, focus on continuous integration—getting the team used to frequent code commits and automated testing. Then, add the continuous delivery part once CI is solid.
7. Communicate the benefits: Get the team on board by clearly explaining the “why.” Highlight how CI/CD reduces deployment risk, speeds up delivery, and improves code quality, making everyone’s lives easier in the long run.
With patience, training, and the right tools, the transition will be smoother, and the team will start seeing the benefits of faster, more reliable software delivery.
I hope this helps
When I led a team through this transition, I found this Trello board checklist to be very helpful. It's based on the book "Continuous Delivery", which is a good reference, but not required to move through the checklist and evaluate your team's maturity in different areas.
https://trello.com/b/Fdd876S8/continuous-delivery-checklist-template
When all was said and done, my team and I found these items to be the real enablers of continuous delivery:
-Automated test coverage
-Small service scope
-Strong telemetry
-Feature flags
-Infrastructure as code and serverless
-High engagement in demos, code review
-Team ownership of production support