Linux——应用软件的生命周期

1. 功能开发
2. 测试：
   1. 功能性测试
      • 对应开发框架的测试用例
   2. 代码的漏洞扫描
      • Web服务器版本
      • 应用开发语言的依赖关系和版本信息
      • 是否会造成类似内存泄露等影响系统性能的问题
   3. 压力测试
3. 应用的部署
   1. 获取应用代码以及应用静态文件的代码包
   2. 将安装包中的文件按照服务器配置的架构，将代码文件上传到指定的位置

传统应用开发生命周期中，使用一个名为“瀑布式开发”的概念。各个部门的人员，各司其职，互相之间的工作联系并不紧密。

“敏捷开发”：开发人员一边开发，一边对已经开发完成的部分，进行测试和集成，提升开发效率。

持续集成：开发人员一边进行开发，同时及时进行应用的集成

1. 一旦检测到代码发生变化，立刻运行测试（自动化出发）
2. 测试无误的情况下，继续进行代码的打包发布（自动完成，无需人工操作）
3. 如果测试出现问题，将问题通知给相关人员(无需人工操作，根据测试结果，自动发生)。继续修改
4. 相关开发人员针对测试中出现的问题进行修改后，此时代码发生变化，回到第一步。

持续部署：一定那检测到新版本程序包的发布，就立刻按照提前规划好的方式进行应用的更新部署。

1. 可以利用puppet chef ansible 等自动化管理软件，配置应用的自动化部署
2. 应用更新策略的选择：
   1. 滚动更新：以K8S中部署的具有10个副本数量要求的deployment为例：
      • K8S中如果没有设置更新比例的情况下，默认使用25%作为控制值
      • 10 * 0.25 = 2.5 取整3 每次更新3个副本的pod
      • 更新的批次安排： 3   3   3   1
      • K8S维持本身的10个pod不变，新调度3个pod，新调度的pod使用新发布的应用 ，此时deployment控制的pod数量为13， 10 个旧版本应用 3 个新版本应用
      • 等待新调度的3个pod返回状态为running之后，移除原本10个pod中的3个 此时deployment控制的pod数量为10，3个新应用 7 旧的应用
        1. 如果新调度的3个pod在指定的时间内，没有返回running状态，则此时更新中止，对应的deployment继续控制10个运行旧版本应用的pod
      • 然后回到第三步，以3个pod为单位，依次更新，最后deployment控制到的pod都是新版本的应用

滚动更新是一种更新策略，在滚动更新的过程中如果出现任何问题，可以进行回滚以实现应用版本回溯，恢复到没有问题的版本。而这种更新策略所规划的更新部署可以通过任意方式实现。Shell 剧本 应答文件

1. 1. 灰度发布：生产环境下的服务器将被分为两个集群。一个集群用来部署灰度发布的应用，一个集群用来部署正常更新的应用。

灰度发布和滚动更新都是为了避免同一个问题，即新版本代码发布到生产环境下，出现问题后，不应该影响用户对于应用的正常访问

1. 1. 蓝绿发布：生产环境下服务器被分为两个集群，一个集群使用绿色表示，一个集群使用蓝色表示，这两套集群环境一致，一般同时只有一个集群开放给用户访问。
      • 蓝色集群部署了稳定版本的应用，绿色集群部署了开发版本的应用
      • 绿色集群中的新版本应用经过测试稳定运行后，将用户的访问全部转发给绿色集群处理
      • 此时蓝色集群不再用户的访问，但是蓝色集群可以用来部署最新版本的应用，并测试其稳定性。

金丝雀测试：在应用更新部署前，一定要在生产环境下进行测试，以验证没有任何问题，才可以进行大规模的应用更新。

代码仓库：保存代码的集中仓库。

代码仓库可以使用传统的文件共享协议进行部署，也可以使用专门的代码仓库软件进行部署。目前大部分公司的代码仓库都是用了支持版本控制功能的应用来进行管理。

常见的版本控制软件：

1. Git
2. Mercuril
3. SVN

Git :

git add //文件提交到暂存区，已经被追踪的文件，也可以提交未追踪的文件

git comm