如何从复制粘贴部署过渡到完整的GitOps

在QCon London会议上,Jemma Hussein Allen分享了InnerSource如何通过共享公司特定逻辑来减少引入GitOps时的开发工作量。她详细介绍了他们从复制粘贴部署到全面采用GitOps的过程,并强调了心理安全环境对于开放和诚实的讨论、解决痛点以及推动创新的重要性。

技术栈与工具

  • 版本控制工具:从Subversion迁移到GitHub,后者是基于Git的分布式版本控制系统。
  • 服务器环境:采用LAMP(Linux、Apache、MySQL、PHP)堆栈,尽管应用运行良好,但重点转向部署自动化。
  • CI/CD工具:选择Jenkins,因其灵活性和丰富的插件集成。
  • 配置管理:继续使用Puppet,因其在最近的部署中表现良好。

GitOps原则

Hussein Allen提到了GitOps的四个原则:

  1. 声明式:系统状态需要声明式定义。
  2. 版本化与不可变:系统状态需要以不可变和版本化的方式存储。
  3. 自动拉取:系统状态自动从源中拉取,无需手动干预。
  4. 持续协调:系统状态持续监控和协调。

她强调,声明式系统状态定义、可靠的版本控制和持续协调是最重要的原则,因为它们带来了更快的开发和部署。而对完全自动化的谨慎态度,主要因为需要全面的自动化测试、高可用性、成熟的监控解决方案以及与团队工作方式的兼容性。

开发者工作空间定制

开发者使用Docker定制工作空间,通过图像注册表下载基础镜像,并在本地开发和测试新功能,然后集成到多环境测试和部署工作流中。这种方法解决了多开发者同时在开发环境中测试不同变化时的隔离和可靠性问题。

开发者反馈与InnerSource

开发者反馈中普遍提到需要“快速启动”指南和构建块来加快GitOps的采用。引入InnerSource能力鼓励开发者创建和贡献这些构建块和样板代码,直接提高了开发者采用新工具的速度。

开发者需求与沟通

随着开发者需求的演变,建立开放对话和心理安全环境对于理解开发者需求至关重要。通过定期联系和离线沟通渠道,确保开发者了解平台路线图及其工作的任何变化,并提供反馈和建议。

访谈摘要

在InfoQ的访谈中,Hussein Allen分享了帮助开发者过渡到新工作方式的策略:

  • 培训与结对编程:通过培训和结对编程帮助开发者熟悉新流程。
  • 展示新流程的好处:与团队产品负责人和利益相关者合作,展示新流程的优势,为开发者提供学习和采用新工具的时间。

她还提到,通过让平台工程师和开发者更紧密地合作,例如“Walk a day in my shoes”活动,可以更好地理解开发者的痛点并改进平台。

阅读 13
0 条评论