chichichi0 2020-04-18
开发写代码演变
1.一个开发单打独斗,撸代码,开发网站,自由自在。
2.多个开发同时开发一个网站,同时改一份代码。但是同时改一个文件会导致冲突。
3.分支结构,每天上班第一件事克隆代码,下班前最后一件事合并代码。
代码发布上线是每一个 IT 企业必须要面临的,而且不管是对开发或者是运维来说,代码上线本身就是一个件非常痛苦的事情,很多时候每一次发布都是一次考验。
为了提高上线的效率,代码上线的方式,方法,工具也不断的发展,基本上可以分为以下几个阶段:
软件在开发者的机器上通过 Ant 或其它脚本手动构建,代码保存在中央源码仓库中,但
是开发者不是经常提交本地的修改。每次需要发布的时候,开发者手动合并修改,这个过程
是相当痛苦的。
在这个阶段,团队有构建服务器,自动化的构建在晚上进行。构建过程只是简单的编译
代码,没有可靠的和可重复的单元测试。然而,开发人员每天提交代码。如果某个开发人员
提的代码和其他人的代码冲突的话,构建服务器会在第二天通过邮件通知团队。所以又一段
时间构建是处于失败状态的。
团队对 CI 和自动化测试越来越重视。无论什么时候版本管理系统中的代码改变了都会
触发编译构建过程,团队成员可以看到是代码中的什么改变触发了这个构建。并且,构建脚
本会编译应用并且会执行一系列的单元测试或集成测试。除了邮件,构建服务器还可以通过
其他方式通知团队成员,如:IM。失败的构建被快速的修复。
自动化的代码质量和测试覆盖率的度量手段有助于评价代码的质量和测试的有效性。代
码质量的构建会产生 API 文档。
CI 和测试紧密相关。如今,像测试驱动开发被广泛地使用,使得对自动化的构建更加
有信心。应用不仅仅是简单地编译和测试,而是如果测试成功会被自动的部署到一个应用服
务器上来进行更多的综合的 end-to-end 测试和性能测试。
验收测试驱动的开发被使用,使得我们能够了解项目的状态。这些自动化的测试使用行
为驱动的开发和测试驱动的开发工具来作为交流和文档工具,发布非开发人员也能读懂的测
试结果报告。由于测试在开发的早起就已经被自动化的执行了,所以我们能更加清楚地了解
到什么已经做了,什么还没有做。每当代码改变或晚上,应用被自动化地部署到测试环境中,
以供 QA 团队测试。当测试通过之后,软件的一个版本将被手工部署到生产环境中,团队也
可以在出现问题的时候回滚之前的发布。
对自动化的单元测试,集成测试和验收测试的信心使得我们可以使用自动化的部署技术
将软件直接部署到生产环境中。但是测试还是有可能不能真正的反映现实的环境