没有项目自动化的日子

我的 IDE 可以完成这项工作。 在 Acme，开发人员在 IDE 中完成所有编码，从浏览源代码、实现新功能、编译和重构代码，到运行单元和集成测试。 每当开发新代码时，他们都会按下 “编译” 按钮。 如果 IDE 告诉他们没有编译错误并且测试通过，他们会将代码签入版本控制，以便可以与团队的其他成员共享。 IDE 是一个功能强大的工具，但每个开发人员都需要首先安装标准化版本才能执行所有这些任务，这是 Joe 在使用仅受最新版本编译器支持的新功能时学到的教训。

它适用于我的盒子。 乔盯着滴答作响的时钟，检查了版本控制中的代码，发现它无法再编译了。 源代码中似乎缺少其中一个类。 他打电话给汤姆，汤姆对代码无法在乔的机器上编译感到困惑。 讨论该问题后，Tom 意识到他可能忘记签入其中一个类，这导致编译过程失败。 团队的其他成员现在被阻止，在 Tom 检查丢失的源文件之前无法继续工作。

代码集成完全是一场灾难。 Acme 有两个不同的开发小组，一个专门负责构建基于 Web 的用户界面，另一个负责服务器端后端代码。 两个团队坐在 Tom 的计算机前，运行整个应用程序的编译，构建可交付成果，并将其部署到测试环境中的 Web 服务器。 当团队发现某些功能未按预期运行时，最初的欢呼声很快就消失了。 有些 URL 根本无法解析或导致错误。 尽管团队编写了一些功能测试，但他们并没有在 IDE 中定期进行测试。

测试过程缓慢得像爬行一样。 质量保证 (QA) 团队渴望获得该应用程序的第一个版本。 正如您可以想象的那样，他们不太乐意测试低质量的软件。 开发团队实施的每一次修复都必须执行相同的手动流程。 团队停下来检查版本控制的新更改，从 IDE 构建新版本，并将可交付成果复制到测试服务器。 每一次，开发商都忙得不可开交，无法为公司增加任何其他价值。 经过数周的测试并向投资者成功演示后，质量检查团队表示该应用程序已准备好迎接黄金时段。

部署变成一场马拉松。 根据经验，团队知道由于不可预见的问题，部署应用程序的结果是不可预测的。 必须设置基础设施和运行时环境，必须为数据库准备种子数据，必须进行应用程序的实际部署，并且需要执行初始运行状况监控。 当然，团队已经制定了行动计划，但每个步骤都必须手动执行。