运维开发宝典065-CICD_jenkins

十一、介绍 CI / CD

在本文档中，我们将概述持续集成，持续交付和持续部署的概念，以及GitLab CI / CD的介绍。

1、为什么要 CI / CD 方法简介

软件开发的连续方法基于自动执行脚本，以最大限度地减少在开发应用程序时引入错误的可能性。从新代码的开发到部署，它们需要较少的人为干预甚至根本不需要干预。

它涉及在每次小迭代中不断构建，测试和部署代码更改，从而减少基于有缺陷或失败的先前版本开发新代码的机会。

这种方法有三种主要方法，每种方法都根据最适合您的策略进行应用。

持续集成(Continuous Integration, CI): 代码合并，构建，部署，测试都在一起，不断地执行这个过程，并对结果反馈。

持续交付(Continuous Deployment, CD):　部署到测试环境、预生产环境。　

持续部署(Continuous Delivery, CD): 将最终产品发布到生成环境、给用户使用。

3、怎么理解持续集成、持续交付、持续部署呢？

1、持续集成

持续集成（英语：Continuous integration，缩写为 CI），一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到共用主线（mainline）上。

这个名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。

持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。

持续集成主要是强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。简单来讲就是：频繁地（一天多次）将代码集成到主干。

持续集成目的在产生以下效益如：

及早发现集成错误且由于修订的内容较小所以易于追踪，这可以节省项目的时间与成本。
避免发布日期的前一分钟发生混乱，当每个人都会尝试为他们所造成的那一点点不兼容的版本做检查。
当单元测试失败或发生错误，若开发人员需要在不除错的情况下还原代码库到一个没有问题的状态，只需要放弃一小部分的更改 (因为集成的次数频繁)。
让 "最新" 的程序可保持可用的状态供测试、展示或发布用。
频繁的提交代码会促使开发人员创建模块化，低复杂性的代码。
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

1.2.2 持续交付

持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。

它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

1.2.3 持续部署

持续部署（英语：Continuous Deployment，缩写为 CD），是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

有时候，持续部署也与持续交付混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

持续部署即在持续交付的基础上，把部署到生产环境的过程自动化。

关键字： CI/CD 持续集成/持续交付/持续部署

2、GitLab CI / CD简介（了解）

GitLab CI / CD是GitLab内置的强大工具，允许您将所有连续方法（持续集成，交付和部署）应用于您的软件，而无需第三方应用程序或集成。

1、GitLab CI / CD 的工作原理

要使用GitLab CI / CD，您只需要一个托管在Git存储库中的应用程序代码库，并在一个名为的文件中指定构建，测试和部署脚本，该文件.gitlab-ci.yml位于存储库的根路径中。

在此文件中，您可以定义要运行的脚本，定义包含和缓存依赖项，选择要按顺序运行的命令以及要并行运行的命令，定义要部署应用程序的位置，以及指定是否将要自动运行脚本或手动触发任何脚本。熟悉GitLab CI / CD后，您可以在配置文件中添加更多高级步骤。

要向该文件添加脚本，您需要按照适合您的应用程序的顺序组织它们，并且这些脚本符合您希望执行的测试。要想象可视化过程，请假设您添加到配置文件中的所有脚本与您在计算机终端上运行的命令相同。

将.gitlab-ci.yml配置文件添加到存储库后，GitLab将检测到它并使用名为GitLab Runner的工具运行脚本，该工具与终端类似。

脚本被分组到作业中，它们一起组成一个管道。.gitlab-ci.yml文件的极简主义示例可以包含：

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version

该before_script属性将在运行任何内容之前为您的应用程序安装依赖项，并且调用的作业run-test将打印当前系统的Ruby版本。它们都构成了在每次推送到存储库的任何分支时触发的管道。

GitLab CI / CD不仅可以执行您设置的作业，还可以显示执行过程中发生的情况，如您在终端中看到的那样：

您可以为应用创建策略，GitLab会根据您定义的内容为您运行管道。您的管道状态也由GitLab显示：

最后，如果出现任何问题，您可以轻松回滚所有更改：

2、基本CI / CD工作流程

这是GitLab CI / CD如何适用于通用开发工作流程的一个非常简单的示例。

假设您已在一个问题中讨论过代码实现，并在本地处理您提出的更改。将提交推送到GitLab中远程存储库中的功能分支后，将触发为项目设置的CI / CD管道。通过这样做，GitLab CI / CD：

运行自动脚本（顺序或并行）到：
- 构建并测试您的应用。
- 使用“评论应用”预览每个合并请求的更改，如您所见localhost。

一旦您对实施感到满意：

让您的代码经过审核和批准。
将功能分支合并到默认分支。
- GitLab CI / CD会自动将更改部署到生产环境中。
最后，如果出现问题，您和您的团队可以轻松地将其回滚。

GitLab CI / CD能够做得更多，但这个工作流程体现了GitLab跟踪整个过程的能力，而无需任何外部工具来交付您的软件。而且，最有用的是，您可以通过GitLab UI可视化所有步骤。

3、首次设置 GitLab CI / CD

要开始使用GitLab CI / CD，您需要熟悉.gitlab-ci.yml配置文件语法及其属性。

本文档介绍了GitLab CI / CD在GitLab页面范围内的概念，用于部署静态网站。虽然它适用于想要从头开始编写自己的Pages脚本的用户，但它也可以作为GitLab CI / CD设置过程的介绍。它涵盖了编写CI / CD配置文件的第一个常规步骤，因此我们建议您通读它以了解GitLab的CI / CD逻辑，并了解如何为任何应用程序编写自己的脚本（或调整现有脚本）。

有关GitLab的CI / CD配置选项的深入视图，请查看 .gitlab-ci.yml完整参考。

4、GitLab CI / CD功能集

使用Auto DevOps轻松设置应用程序的整个生命周期。
使用GitLab Pages部署静态网站。
将您的应用程序部署到不同的环境。
使用Review Apps预览每个合并请求的更改。
使用Container Registry开发安全的私有Docker镜像。
安装自己的GitLab Runner。
安排管道。
使用安全测试报告检查应用程序漏洞。

十二、Jenkins CI/CD

1、 Jenkins CI/CD 流程图

说明：这张图稍微更形象一点，上线之前先把代码git到版本仓库，然后通过Jenkins 如Java项目通过maven去构建，这是在非容器之前，典型的自动化的一个版本上线流程。那它有哪些问题呢？

如：它的测试环境，预生产环境，测试环境。会存在一定的兼容性问题（环境之间会有一定的差异）

说明：它这里有一个docker harbor 的镜像仓库，通常会把你的环境打包为一个镜像，通过镜像的方式来部署。

Jenkins持续集成01—Jenkins服务搭建和部署

2、介绍 Jenkins

1、前言

Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。

Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中（例如Apache Tomcat）。它支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令。Jenkins的主要开发者是川口耕介。Jenkins是在MIT许可证下发布的自由软件。

2、Jenkins功能

1、持续的软件版本发布/测试项目。

2、监控外部调用执行的工作。

3、Jenkins概念

　　Jenkins是一个功能强大的应用程序，允许持续集成和持续交付项目，无论用的是什么平台。这是一个免费的源代码，可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。

4、Jenkins目的

① 持续、自动地构建/测试软件项目。

② 监控软件开放流程，快速问题定位及处理，提示开放效率。

5、Jenkins特性

① 开源的java语言开发持续集成工具，支持CI，CD。

② 易于安装部署配置：可通过yum安装,或下载war包以及通过docker容器等快速实现安装部署，可方便web界面配置管理。

③ 消息通知及测试报告：集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知，生成JUnit/TestNG测试报告。

④ 分布式构建：支持Jenkins能够让多台计算机一起构建/测试。

⑤ 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。

⑥ 丰富的插件支持:支持扩展插件，你可以开发适合自己团队使用的工具，如git，svn，maven，docker等。

6、产品发布流程

产品设计成型 -> 开发人员开发代码 -> 测试人员测试功能 -> 运维人员发布上线

持续集成（Continuous integration，简称CI）

持续交付（Continuous delivery）

持续部署（continuous deployment）

3、安装Jenkins

1、安装JDK

Jenkins是Java编写的，所以需要先安装JDK，这里采用yum安装，如果对版本有需求，可以直接在Oracle官网下载JDK；也可自己编译安装。

[root@jenkins ~]# yum install -y java-1.8.0

2、安装Jekins

[root@jenkins ~]# cd /etc/yum.repos.d/

[root@jenkins yum.repos.d]# wget http://pkg.jenkins.io/redhat-stable/jenkins.repo

[root@jenkins ~]# rpm --import http://pkg.jenkins.io/redhat/jenkins.io.key

[root@jenkins ~]# yum install -y jenkins

3、修改配置文件

（1）查询yum下载Jenkins安装的文件

[root@jenkins ~]# rpm -ql jenkins

/etc/init.d/jenkins         # 启动文件
/etc/logrotate.d/jenkins    # 日志分割配置文件
/etc/sysconfig/jenkins      # jenkins主配置文件
/usr/lib/jenkins            # 存放war包目录
/usr/lib/jenkins/jenkins.war   # war 包 
/usr/sbin/rcjenkins         # 命令
/var/cache/jenkins          # war包解压目录 jenkins网页代码目录
/var/lib/jenkins            # jenkins 工作目录
/var/log/jenkins             # 日志

（2）创建Jenkins主目录

[root@jenkins ~]# mkdir /data/jenkins -p

[root@jenkins ~]# chown -R jenkins.jenkins /data/jenkins/

（3）修改配置文件

[root@jenkins ~]# vim /etc/sysconfig/jenkins

配置文件说明

[root@Jenkins ~]# grep "^[a-Z]" /etc/sysconfig/jenkins
JENKINS_HOME="/var/lib/jenkins"    #jenkins工作目录
JENKINS_JAVA_CMD=""
JENKINS_USER="jenkins"       # jenkinx启动用户
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
JENKINS_PORT="8080"          # 端口
JENKINS_LISTEN_ADDRESS=""
JENKINS_HTTPS_PORT=""
JENKINS_HTTPS_KEYSTORE=""
JENKINS_HTTPS_KEYSTORE_PASSWORD=""
JENKINS_HTTPS_LISTEN_ADDRESS=""
JENKINS_DEBUG_LEVEL="5"
JENKINS_ENABLE_ACCESS_LOG="no"
JENKINS_HANDLER_MAX="100"     # 最大连接
JENKINS_HANDLER_IDLE="20"
JENKINS_ARGS=""

（4）开启Jenkins服务

[root@jenkins bin]# systemctl start jenkins

检查端口信息

[root@Jenkins ~]# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1213/sshd           
tcp6       0      0 :::8080                 :::*                    LISTEN      1672/java           
tcp6       0      0 :::22                   :::*                    LISTEN      1213/sshd

（5）网页打开配置

打开192.168.130.110:8080/

① 为了安全考虑，首先需要解锁Jenkins，请在/var/lib/jenkins/secrets/initialAdminPassword中查看文件。

在Jenkins服务器上查询管理员密码

[root@centos7-1 ~]# cat /data/jenkins/secrets/initialAdminPassword

250d0360e2a149dbb7402f96a26945e2

② 选择需要安装的插件

选择默认推荐即可，会安装通用的社区插件，剩下的可以在使用的时候再进行安装。

开始安装，由于网络原因，有一些插件会安装失败。

③ 设置Admin用户和密码

④ 安装完成

⑤ 登录Jenkins

4、安装完后，简单的配置

1、系统配置

① 系统消息：Welcome to Jenkins~

② 全局属性--->环境变量，可根据自己的项目添加；如：gitlab：

③ 扩展邮件通知（用于之后项目构建后发送邮件）

④ 邮件配置

　　管理监控配置--->系统管理员邮件地址：along@163.com，要和下面的用户名一致； Lysh1311

　　邮件通知，配置如下：可以点击测试，是否配置成功

2、全局工具配置

如果你持续集成需要用的哪些工具，就需要在这里添加配置；后边持续集成中，将会详细讲解；

这里只举例：添加JDK工具

点击新增---> 取消自动安装 ---->然后查询Jenkins服务器上JDK的路径，填写JAVA_HOME ---> 保存即可

3、插件管理

这里有可更新、可选未安装插件、已安装插件；可以通过过滤快速查找

5、jenkins 下载插件失败处理办法

jenkins 下载插件失败,提示：

java.io.IOException: Downloaded file /app/jenkins_home/plugins/jacoco.jpi.tmp does not match expected SHA-1, expected 'CtK02wHdFOxTutqhUQzmue6uvpg=', actual 'YGO05utKyaaFzpGCgCE95GS0WsU='
	at hudson.model.UpdateCenter.verifyChecksums(UpdateCenter.java:1783)
	at hudson.model.UpdateCenter.access$1100(UpdateCenter.java:147)
	at hudson.model.UpdateCenter$InstallationJob.replace(UpdateCenter.java:1934)
	at hudson.model.UpdateCenter$UpdateCenterConfiguration.install(UpdateCenter.java:1178)
	at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1653)
	at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1848)
	at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1624)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110)
	at java.lang.Thread.run(Thread.java:745)

查找资料，说是中国源的问题。需要换个源就可以，换源的方法：

jenkins->系统管理->管理插件->高级
选择升级站点

把：http://updates.jenkins-ci.org/update-center.json

换成：http://mirror.esuni.jp/jenkins/updates/update-center.json

镜像地址查询：

http://mirrors.jenkins-ci.org/status.html

1.4 Jenkins使用

1.4.1 创建一个新的任务

创建一个新的任务

输入项目的名称，选择构建只有分风格的软件

1.4.2 将Jenkins与gitlab联合

创建公钥和私钥

[root@Jenkins ~]# ssh-keygen 
Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:5SGYye8oxCKFJjddb4W8JC0RAQhBWCvuG8aZL8eMJs4 root@Jenkins
The key's randomart image is:
+---[RSA 2048]----+
|==....=* ..      |
|...o oo==.       |
|+.= . =++.o      |
|++ o   o.+ .     |
|... o   S .      |
|o.oo   o         |
| B+ . . .        |
|++++ .           |
|+Eo.             |
+----[SHA256]-----+
[root@Jenkins ~]# cat .ssh/id_rsa.pub 
[root@Jenkins ~]# cat .ssh/id_rsa

在gitlab****中添加公钥id_rsa.pub

在jenkins****中添加私钥id_rsa

在首页中，点击项目名称的下拉监听

选择源码管理，先将gitlab的项目地址复制过来

选择SSH密钥和证书，然后选择直接输入，将私钥复制到下框中即可

添加完成后，点击保存

选择刚才创建的证书，完成后，选择构建

选择构建

拉到最底部，选择使用shell脚本

脚本内容

创建测试环境

[root@Jenkins ~]# mkdir -p /data/www
[root@Jenkins ~]# chown -R jenkins.jenkins /data/

选择构建后的操作，让每次构建完成后都将结果发送给管理员

1.4.3 测试手动集成

回到主页，点击右侧的按钮进行测试

部署完成

查看部署日志

查看部署结果

[root@Jenkins ~]# ll /data/www/
总用量 4
-rw-r--r-- 1 jenkins jenkins 4 11月 30 21:22 flag
-rw-r--r-- 1 jenkins jenkins 0 11月 30 21:22 README.md

1.4.4 自动测试（gitlab主动通知Jenkins测试）

该功能会使用到一个插件 gitlab plugin

配置gitlab认证

添加一个新的凭证

从gitlab的设置中将 token复制过来

将复制的token粘贴到api token中，点ok

在系统配置中找到Gitlab 将信息进行填写，Credentials 选择刚刚创建对的即可

打开项目，编辑项目的构建触发器

在gitlab上配置连接jenkins ，将Jenkins的Secret token 与Build URL 复制到gitlab中

保存之前先进程测试，测试成功后进行保存

需要设置允许请求

在gitlab进行上传文件，可以测试。

在日志中显示是 Started by GitLab push by Administrator 即表示自动集成成功

1.5 代码上线方案

1、早期手动部署代码

纯手动scp上传代码。

纯手动登陆，Git pull 或者SVN update。

纯手动xftp上传代码。

开发发送压缩包，rz上传，解压部署代码。

缺点：

全程运维参与，占用大量时间。

如果节点多，上线速度慢。

人为失误多，目录管理混乱。

回滚不及时，或者难以回退。

2、合理化上线方案

1、开发人员需在个人电脑搭建LAMP环境测试开发好的网站代码，并且在办公室或 IDC机房的测试环境测试通过，最好有专职测试人员。

2、程序代码上线要规定时间，例如：三天上线一次，如网站需经常更新可每天下午 20点上线，这个看网站业务性质而定，原则就是影响用户体验最小。

3、代码上线之前需备份，网站程序出了问题方便回退，另外，从上线技巧上讲，上传代码时尽可能先传到服务器网站临时目录，传完整后一步mv过去，或者通过In做软链接— 线上更新代码的思路。如果严格更新，把应用服务器从集群节点平滑下线，然后更新。

4、尽量由运维人员管理上线，对于代码的功能性，开发人员更在意，而对于代码的性能优化和上线后服务器的稳定，运维更在意服务器的稳定，因此，如果网站宕机问题归运维管，就要让运维上线，这样更规范科学。否则，开发随意更新，出了问题运维负责，这样就错了，运维永远无法抬头。

图·web****代码规范化上线流程图

3、大型企业上线制度和流程

JAVA代码环境，上线时，有数台机器同时需要更新或者分批更新 ↓

1).本地开发人员取svn代码。当天上线提交到trunk，否则，长期项目单开分支开发，然后在合并主线(trunk)
2).办公内网开发测试时，由开发人员或配置管理员通过部署平台jenkins实现统一部署，（即在部署平台上控制开发机器从svn取代码，编译，打包，发布到开发机，包名如idc_dep.war）.
3).开发人员通知或和测试人员一起测试程序，没有问题后，由配置管理员打上新的tag标记。这里要注意，不同环境的配置文件是随代码同时发布的。
4).配置管理员，根据上一步的tag标记，checkout出上线代码，并配置好IDC测试环境的所有配置，执行编译，打包(mvn,ant)(php不需要打包)，然后发布到IDC内的统一分发服务器。
5).配置管理员或SA上线人员，把分发的程序代码内容推送到相关测试服务器（包名如idc_test.war），然后通知开发及测试人员进行测试。如果有问题向上回退，继续修改。
6).如果IDC测试没有问题，继续打好tag标记，此时，配置管理员，根据上步的tag标记，checkout出测试好的代码，并配置好IDC正式环境的所有配置，执行编译，打包(mvn,ant)(php不需要打包)，然后发布到IDC内的统一分发服务器主机，准备批量发布。
7).配置管理员或SA上线人员，把分发的内容推送到相关正式服务器（包名如idc_product.war）,然后通知开发及测试人员进行测试。如果有问题直接发布回滚指令。

　　 IDC正式上线的过程对于JAVA程序，可以是AB组分组上线的思路，即平滑下线一半的服务器，然后发布更新代码，重启测试，无问题后，挂上更新后的服务器，同时再平滑下线另一半的服务器，然后发布更新代码测试（或者直接发布后，重启，挂上线）

4 、php程序代码上线的具体方案

　　对于PHP上线方法：发布代码时（也需要测试流程）可以直接发布到正式线临时目录，然后mv或更改link的方式发布到正式上线目录，不需要重启http服务。这是新朗，赶集的上线方案。

5 、JAVA程序代码上线的具体方案

对于java上线方法:较大公司需要分组平滑上线（如从负载均衡器上摘掉一半的服务器），发布代码后，重启服务器测试，没问题后，挂上上好线的一半，再下另外一半。如果前端有DNS智能解析，上线还可以分地区上线若干服务器，逐渐普及到全国的服务器，这个被称为“灰度发布”，在后面门户网站上线的知识里我们在讲解。

6 、代码上线解决方案注意事项(纯干货)

1).上线的流程里，办公室测试环境-->IDC测试环境-->正式生产环境，所有环境中的所有软件均应版本统一，其次尽量单一，否则将后患无穷，开发测试成功，IDC测试就可能有问题（如:操作系统，web服务器，jdk,php,tomcat,resin等版本）
2).开发团队小组办公内部测试环境测试（该测试环境属于开发小组维护，或定时自动更新代码），代码有问题返回给某开发人员重新开发。
3).有专门的测试工程师，程序有问题直接返回给开发人员（此时返回的一般为程序的BUG，称为BUG库），无问题进行IDC测试
4).IDC测试由测试人员和运维人员参与，叫IDCtest,进行程序的压力测试，有问题直接返回给开发人员，无问题进行线上环境上线。
5).数台服务器代码分发上线方案举例（JAVA程序）　　
A:假设同业务服务器有6台，将服务器分为A,B两组，A组三台，B组三台，先对A组进行从负载均衡器上平滑下线，B组正常提供服务，避免服务器因上线影响业务。　　
B:下线过程是通过脚本将A组服务器从RS池（LVS,NGINX,HAPROXY,F5等均有平滑方案）中踢出，避免负裁均衡器将请求发送给A组服务器（此时的时间应该为网站流量少时，一般为晚上）　　
C:将代码分发到A组服务器的站点目录下，对A组服务器上线并重启服务，并由专业的测试人员进行访问测试，测试成功后，挂上A组的服务器，同时下线B组服务器，B组代码上线操作测试等和A组相同，期间也要观察上线提供服务的服务器状况，有问题及时回滚。
6).特别说明：如果是PHP程序，则上线可以简单化，直接将上线代码（最好全量）发布到所有上线服务器的特定目录后，分发完成后，一次性mv或ln到站点目录，当然测试也是少不了的。测试除了人员测试外，还有各种测试脚本测试各个相关业务接口。``
7).大多数门户公司的前端页面都已经静态化或者cache了，因此，动态的部分访问平时就不会特别多，流量低谷时就更少了。再加上是平滑上下线

发表于 2026-09-06 16:07 云计算磊哥阅读(14) 评论(0) 收藏举报

刷新页面返回顶部