可控的项目

对于一个项目，想要「可控」至少需要具备以下因素：

  1. 明确的负责人。负责人应知晓或间接知晓该项目的一切业务逻辑及其分工，负责人具有该项目内一切技术方案选型、实施的决定权；若发生故障，负责人为第一责任人。
  2. 确定的行为。项目内调用的所有自研模块、第三方模块行为（输入-输出）必须是确定的，同时有基本的单元测试证明其确定性；若自研模块不满足此标准，应修改到满足为止，若第三方模块不满足此标准，应弃用。
  3. 必要的文档。应提供必要的文档描述关键行为，另外用于取代口头交流，以及备忘之用。
  4. 透明的协作状态。多人协作时，成员应尽可能透明当前状态，使项目早期能够低成本解决冲突（代码或方案），见《开发约定 · GitHub 协作》。
  5. 安全的代码。production 和 staging 的配置不得在版本控制中出现，杜绝因环境错误导致生产事故的可能性，见《开发约定 · GitHub 协作》。
  6. 完整周期的掌控。负责人及研发应知晓整个从开发到上线后的所有环节及依赖项，并尽可能让每个环节在己方掌控范围。包括项目开发阶段、构建发布阶段、运维阶段。

项目开发阶段

构建发布阶段

  1. 通常，一个完整的项目生产环节包括：代码编写、程序构建、应用部署、应用上线
  2. 构建、部署、上线 属于项目研发的一部分，不能割裂。即上述逻辑均可以在项目代码中找到，并且能够在最大程度上脱离外部依赖（人或物）独立跑通完整流程
  3. 因此，对于指定项目，负责人需要知晓并完善上述环节，同时建议其他参与人员在指定时间内熟悉整个流程的逻辑
  4. 实践案例 xxx: Docker + Jenkins（在项目中定义 Dockfile 和 Jenkinsfile）

运维阶段

  1. 生产环境服务运维，做到有逻辑可循，有记录可查，有监控，有告警。
  2. 运行时的执行逻辑（如定时脚本触发逻辑），也应在项目代码中找到（用常规编程或者在 Dockerfile 中定义），而非依赖宿主服务器的 crontab
  3. 实践案例 xxx

……持续完善中