Our Journey from in-House CD System to Open Source

Talked at KubeDay Japan 2024: https://sched.co/1egpT

We will share our challenging journey of providing a Continuous Delivery (CD) system as an in-house infrastructure, and subsequently releasing it as open source. We will delve into why we decided to offer a CD system within our organization, and the actual initiatives we undertook to achieve this. These initiatives include offering a control plane as an in-house SaaS, enriching in-house support, conducting in-house Office Hours, and finally, making it public as an open source software. We will also highlight the unique strategies and innovations that we implemented during this process. This talk will provide valuable insights for those who are considering similar initiatives, and it will also help to enrich the ecosystem by sharing our experiences and lessons learned.

Transcript

1. Our Journey from in-House CD System to Open Source 2024/08/27 KubeDay Japan 2024
2. Yoshiki Fujikane • CyberAgent, Inc. (Japan) • Developer Productivity Group • Software Engineer • A maintainer of PipeCD About me @ffjlabo @ffjlabo 2
3. Agenda • Why do we need to create a new CD? • Why OSS? • In-house OSS challenge 3
4. Why do we need to create a new CD? 4
5. Our Company Structure 5
6. Key points • Each team adopt a different platform. • Each team has a different level of CD maturity. • There is no dedicated person or team for CD. 6
7. Existing solutions • Spinnaker: Rich support for the various platform, but a little hard to maintain as an internal platform • ArgoCD: GitOps for k8s • FluxCD: GitOps for k8s • … and so on → Existing tools and services couldn’t meet requirements. 7
8. Cross-sectional CD infrastructure 8
10. The One CD for All {applications, platforms, operations} • A GitOps style continuous delivery platform that provides consistent deployment and operations experience for any applications Build your own Progressive Delivery Pipeline • Built In support for Progressive Delivery (Canary, Blue/Green…) • Automatically analyze, rollout with metrics 10
11. PipeCD operation model 11
12. Internal Platform 12
13. OSS × Internal Platform 13
14. • 4000s commits / 90 contributors • CNCF Sandbox from 2023 14
15. But why OSS? 15
16. Key points • Product sustainability • Product branding • Company-wide technology branding 16
17. Product sustainability • Increase project transparency to increase product discussion • Circulate CD solutions from outside and inside and sublimate them into better products • Compensate for the shortage of resources 17
18. Product branding 🤔 What do you think about when selecting technology as an engineer? • Are the functions complete? • Will this tool continue to be developed? • GitHub stars • Is it a more popular tool? … -> Increase reputation for internal teams while evaluating PipeCD vs other CDs 18
19. Company-wide technology branding • Creating and providing a product as OSS itself is proof of technology investment. • We will also create an OSS culture within the company. 19
20. In-house OSS challenge 20
21. PipeCD at CyberAgent 21
23. Lesson learned from our experience of operating an OSS CD in house 23
24. CS Support on Slack • Fast response to the request from users via slack Leveling the request by users themselves via priority label • P1,P2,P3,P4 • Some interesting tickets could be translated and listed in the public repo later 24
25. Office Hour • Discuss FAQs and new features regarding PipeCD • Collect requests from users based on questions and chats, and create a roadmap. 25
26. Office Hour • The place for sharing information among users 26
27. Collaboration with other teams • Contributions from external teams 27
28. Don’t die alone 28
29. Thanks to contributions 29
30. Toward the future • Making devs able to public issues/discussions on public repo • More and more contributions from internal and external • External community touch and presents a lot …. 30
31. Join Us! • Our team and internal PipeCD user join KubeDay booth today!! • Let’s talk with us !!! • Public Meeting both English and Japanese! 31
32. Tutorial Reference 32