场景一：持续集成的需求
多位开发人员各自在自己的机器上编写代码，进度看起来还不赖！但是，在我们需要构建应用程序新版本时，大家就要将各自的代码进行合并。由于开发人员独立编写的代码经常存在着关联，合并代码时就会出现冲突，这可能要花费额外的两小时到两天不等的时间来手工调整代码以实现代码的合并。
成功合并代码仅仅是完成构建的第一步，接下来还需要进行代码编译，同时进行单元测试和代码质量检查，如果时间允许，最好还能一并完成系统基本功能测试，这样我们才能知道构建最终是成功的，编译出来的包可以健康地发布到集成测试环境和UAT环境，进一步执行详细的功能性测试以及非功能性测试。
问题一：如何能实现上述持续集成的目标，让每一位开发人员可以随时提交代码，然后系统自动进行代码合并、代码编译、代码质量检查和自动化测试呢？
场景二：持续部署的需求
昨天，老板让你给客户演示一下产品很不错的新特性，但你却什么都演示不了。所有新功能都只开发了一半，没人能让这个系统运行起来。你能拿到代码，可以编译，所有的单元测试在持续集成服务器上都能跑过，但是还要花几天才能把这个新版本发布到对外公开的UAT环境中。这种临时安排的商务演示活动算不上不合理吧？
在生产环境中发现了一个严重缺陷，它每天都在让你的公司蒙受损失。你也知道怎么修复它：只要在这个三层架构的系统中修改那个被这三层都调用的库上的一行代码，然后再修改一下数据库中对应的表即可。但是，上次发布新版本到生产环境时，你花掉了整个周末的时间，而且直到凌晨三点才完活儿。另外，上次执行部署的那个家伙在不久之后因厌倦这样的工作辞职了。你清楚地知道，下次发布肯定不是一个周末就能搞定的。也就是说，该系统在工作日也会停机一段时间。唉，要是业务人员也能理解我们的问题就好了。
软件发布应该是一个快速且可重复的过程。现在，很多公司都会在一天内发布很多次，甚至对于那些代码非常复杂的代码库来说这样做也是可能的。在你的公司里，仅涉及一行代码的改动需要花多长时间才能部署上线？你的处理方式是否是可重复且可靠的呢？不少组织在经过深入的业务流程重组后，对于某一关键的修改，团队做到了小时级别甚至分钟级别的发布。
问题二：如何建立自动化的工具链，来让开发人员、测试人员、运维人员可以自助式获取开发、测试和生产环境资源，在自动执行一系列功能性测试、非功能性测试甚至验收测试之后，大家能一键式自动化、低风险地将应用部署到生产环境中呢？
课程简介：
转播
分享
淘帖
()