17、软件开发部署与持续集成全解析

软件开发部署与持续集成全解析

在当今的软件开发领域，将代码从开发环境顺利部署到生产环境是一项至关重要的任务。这其中涉及到诸多环节，包括域名购买、代码管理、持续集成与部署等。下面我们就来详细探讨这些内容。

域名购买与服务部署

如果你打算为自己的网络服务购买一个域名，在考虑好听的名称之前，先在 DNS 提供商的网站上查看域名的可用性和价格。购买域名后，需要将其连接到运行服务的主机的 IP 地址，主机和域名提供商都会提供清晰的操作说明。之后，只需在浏览器中输入域名，就能访问你的服务了。

如果觉得这些操作比较复杂，也有很多服务可以简化这个过程：
- Wix（https://www.wix.com/） ：提供从简单的拖放式网站创建到域名注册的一站式服务，你可以即时构建网站、注册域名，网站会立即在网络上可用。
- Squarespace（https://www.squarespace.com/） ：允许创建网站，你可以从数百个精美的模板中选择，并立即注册域名。

如果你想自己构建服务，但希望自动化托管部分，避免每次更改文件都手动复制粘贴到服务器，可以使用以下自动化解决方案：
- AWS（https://aws.amazon.com/）
- Heroku（https://www.heroku.com/）
- Google Cloud（https://cloud.google.com/）
- Google Firebase（https://firebase.google.com/）

这些服务提供简单的命令行界面，只需几条命令就能轻松部署服务。

何时开始考虑部署

从开发的一开始就要考虑部署问题。你需要了解服务如何与所使用的部署工具集成，提前准备好所需的基础设施，这样当代码准备好发布时，只需点击一个按钮就能完成部署。

在编写代码初期，可能还没有可部署的内容。可以模拟环境，创建架构中各个部分（如数据库、后端和前端）的模拟对象并上线，确保其正常运行，不断改进部署流程，直至实现 100% 或接近 100% 的自动化。

在部署前，要确保所有测试都通过，并且如果有多个开发者参与，代码能够轻松集成。这个将多个用户的代码集成到同一代码库，并在部署前运行测试和其他代码检查的自动化过程，称为持续集成（Continuous Integration）。

进一步地，除了集成和自动化测试，还要准备好将代码发布到生产环境，这就是持续交付（Continuous Delivery）。将持续交付的结果自动部署到托管平台，就实现了持续部署（Continuous Deployment），简称 CI/CD。

代码存放位置

为了能够持续运行软件集成、构建和部署的自动化流程，代码不能仅仅存放在本地机器上，需要一个集中的地方，让所有参与开发的人随时都能获取代码，并且代码更新后能及时同步。

像 Dropbox、Google Drive 或 iCloud 等云服务虽然是集中式的，可以共享访问、修改和添加文件，但在处理多人同时编辑文件时会出现问题。例如，多人同时修改一个文件，后上传的文件会覆盖先上传的文件，导致部分更改丢失。

因此，我们需要版本控制系统（VCS），如 SVN（https://subversion.apache.org/）、GIT（https://git-scm.com/）、Mercurial（https://www.mercurial-scm.org/）等。其中，GIT 是开发者中最受欢迎的，它提供了一系列简单而强大的命令来管理源代码：
- git init ：在指定文件夹创建 git 仓库。
- git pull ：拉取最新更改。
- git add ：添加新文件。
- git commit ：提交更改，并提供有意义的提交信息。
- git push ：将提交的更改推送到远程仓库。

每个提交都有一个关联的哈希值，你可以随时将代码回退到任何提交版本。如果同事也在修改同一个文件，git 会确保所有更改都能正确合并。若出现冲突，git 会发出警告并要求解决冲突。

你可以使用这个可视化工具（http://git-school.github.io/visualizing-git/）来练习 git 操作。

为了让所有人都能访问代码，还需要一个云服务来托管 git 仓库，常见的有：
- Bitbucket（https://bitbucket.org/）
- GitLab（https://about.gitlab.com/）
- GitHub（https://github.com/）

我们通常使用 GitHub，因为它提供了很多有用的工具和 CI/CD 集成。GitLab 也越来越受欢迎，它集成了完整的 CI/CD 管道，前端使用 Vue.js 编写。

持续集成与自动化测试

我们已经了解了如何使用 Git 进行代码的持续集成，确保所有更改都能被妥善存储和版本控制。接下来，我们要讨论每次推送代码时如何自动检查代码。

在之前的学习中，我们学会了编写不同类型的测试。例如，后端单元测试可以使用 mvn clean test -Ptest 命令运行，前端单元测试使用 npm test 命令，端到端测试使用 npm run e2e 命令。

除了测试，还可以进行其他检查，如代码质量、测试覆盖率、特定代码规范（如每个文件的最大行数）等。你可以配置这些检查的阈值，并定义相应的命令来验证。

可以通过创建预提交钩子（pre-commit hook）或预推送钩子（pre-push hook）来自动运行这些检查，但如果检查项目较多，会减慢本地开发过程。通常，本地只运行最关键的检查，如单元测试，其他质量检查交给持续集成工具。

以下是一些常用的持续集成工具：
- Travis CI（https://travis-ci.org/） ：连接到 TravisCI 平台，使用其界面连接到 GitHub 仓库，并创建配置文件，指定检查代码所需的命令。
- CircleCI（https://circleci.com/） ：与 TravisCI 的设置和配置类似。
- Jenkins（https://jenkins.io/） ：虽然界面不太美观且操作繁琐，但功能强大。
- ConcourseCI（https://concourse-ci.org/） ：使用 yaml 配置文件进行配置，提供精美的构建管道可视化界面。

我们推荐使用 TravisCI 或 CircleCI，因为它们易于与 GitHub 集成，用户界面友好，学习曲线低，能在几分钟内完成基本的持续集成设置。

下面是一个简单的持续集成流程 mermaid 流程图：

graph LR
    A[代码修改] --> B[提交代码]
    B --> C[触发持续集成工具]
    C --> D[运行测试和检查]
    D --> E{测试通过?}
    E -- 是 --> F[持续交付和部署]
    E -- 否 --> G[修复代码]
    G --> B

综上所述，在软件开发过程中，合理选择域名购买和部署服务，提前规划部署流程，选择合适的代码存放位置和持续集成工具，对于提高开发效率和软件质量至关重要。通过持续集成和自动化测试，我们可以确保代码的稳定性和可靠性，为软件的顺利发布和持续更新提供有力保障。

软件开发部署与持续集成全解析

持续交付与部署

持续交付是在持续集成的基础上，将代码准备好发布到生产环境的过程。这意味着要根据具体情况，对代码进行一系列处理，使其能够在生产环境中正常运行。

例如，如果代码只是一些 HTML、JavaScript 和 CSS 文件，可能直接复制到 Web 服务器就可以投入生产。但如果使用了框架或预处理器，就需要运行一些命令将代码转换为普通的 HTML、CSS 和 JS 文件。以使用 Vue.js 的应用为例，使用 Vue webpack 模板创建的应用，可使用 npm run dist 命令来准备代码进行分发。对于 Java 项目，则需要使用 mvn clean install 命令来编译服务器。

在持续交付过程中，需要在 CI/CD 工具的配置文件中指定所有必要的命令，将代码转换为可运行的工件。完成代码构建后，就可以进行部署。部署的方式因应用的托管形式而异。如果只是将文件复制到远程服务器，可以让 CI/CD 工具使用 SCP（安全复制协议）复制构建生成的文件。若使用 Heroku 等平台，由于其本身提供构建功能，在 Travis 成功验证测试后，告知 Heroku 可以进行代码构建和部署即可。

对于是否在所有检查通过后自动部署，存在不同观点。有些人认为自动化部署存在风险，特别是对于依赖服务的大量用户的情况。通常的做法是设置一个与生产环境非常相似的预发布环境（staging environment），让 CI/CD 工具持续部署到该环境，手动检查一切正常后，再点击按钮将其部署到生产环境，这种方式称为“晋升到生产”（promoting to production）。

以下是持续交付与部署的步骤表格：
|步骤|描述|
| ---- | ---- |
|持续交付准备|根据代码情况运行相应命令，如 npm run dist 或 mvn clean install ，将代码转换为可分发形式|
|部署|根据托管形式选择部署方式，如使用 SCP 复制文件或告知托管平台进行构建部署|
|预发布检查|将代码部署到预发布环境，手动检查是否正常|
|生产部署|确认预发布环境正常后，点击按钮将代码部署到生产环境|

团队分工与实践案例

在软件开发的部署和持续集成过程中，团队成员的分工至关重要。在项目初期，由于资源有限，开发者可能需要承担实现交付步骤自动化的任务。随着产品的成熟和开发团队规模的扩大，可以设立专门的团队来处理这些工作，如 DevOps（开发和运维工程师）、基础设施团队、安全工程师、SRE（站点可靠性工程师）等，他们的职责是将开发与维护产品所需的运维工作连接起来，并尽可能实现自动化。

以下是不同公司的实践案例：
- Feedzai ：初期团队规模较小，没有 CI/CD 流程，产品是独立的软件包，以 2 个月为一个发布周期，每个周期结束时会为不同平台提供可执行文件和发布说明。
- Gymondo ：具备 CI 和 CD，测试和预发布环境实现自动部署，生产环境只需简单手动步骤即可实现零停机发布。
- OptioPay ：代码审查、批准和测试通过后，点击按钮即可将功能代码推送到生产环境，没有固定的发布日期。

理想的情况是能够快速频繁地发布新功能，同时设定一些特殊的“发布日”来庆祝，提升团队士气。

与 DevOps 专业人员的对话

为了更深入了解 DevOps 的工作内容和职业发展，我们与在 Zendesk 工作的 Anderson 进行了交流。

DevOps 的定义和作用

Anderson 表示，DevOps 的核心是将开发人员和运维人员结合起来，建立一个从开发到将软件投入生产的流程。过去，开发人员和运维人员之间沟通困难，难以找到共同的工作基础。而 DevOps 文化注重如何将反馈循环尽快传递给开发人员，以便及时发现和修复问题，降低成本，减少生产环境中的 bug 数量。

成为 DevOps 工程师的路径

Anderson 介绍，如今有一些 DevOps 相关的认证，如 Amazon AWS 的 DevOps 认证。他自己毕业于计算机科学专业，有软件工程背景，但大部分经验来自系统管理。他发现传统的运维工作缺乏代码管理基础设施的手段，扩展性差，于是开始学习软件工程，创建自己的工具来支持部署和组织战略。实际上，无论是软件工程师还是系统管理员，都可以通过学习和补充自己不足的方面，成为 DevOps 工程师。对于没有计算机科学背景或系统管理经验的人，也可以通过遵循 Amazon 建议的三个基础认证（包括开发、运维和架构），学习 DevOps 相关原理，逐步成为 DevOps 专业人员。

实际工作中的案例

• 重大问题解决 ：Anderson 曾在升级大学的认证系统时，由于没有自动化流程，手动更改配置文件，匆忙中误关了新服务器，导致整个大学系统停机约一小时。这让他深刻认识到自动化的重要性。有了良好的自动化机制，就可以避免手动操作带来的错误，确保流程按预期执行。
• 成功项目经验 ：他曾负责为巴西政府搭建整个云基础设施，将原本需要约 3 个月才能完成的复杂基础设施配置时间缩短到约 5 分钟。如今，该公司仍在向巴西的机构和行政部门销售该解决方案。
• 有趣的故事 ：有一次凌晨 3 点，他负责的巴西数据中心火警警报响起，所有机器自动关闭。他和同事在 4 个小时内成功重启了整个基础设施。虽然这是一次虚惊，但最后大家一起吃披萨、欢笑，并在第二天庆祝，体现了团队的凝聚力。

Anderson 强调，热爱自己的工作是非常重要的，这是他生活的基本哲学。即使会遇到一些不太理想的任务，但总体上要做自己喜欢的事情。

下面是一个 DevOps 工作流程的 mermaid 流程图：

graph LR
    A[开发代码] --> B[代码审查]
    B --> C[持续集成]
    C --> D[自动化测试]
    D --> E{测试通过?}
    E -- 是 --> F[持续交付]
    E -- 否 --> A
    F --> G[预发布环境部署]
    G --> H[手动检查]
    H --> I{检查通过?}
    I -- 是 --> J[生产环境部署]
    I -- 否 --> A

综上所述，软件开发的部署和持续集成是一个复杂而关键的过程，涉及域名购买、代码管理、持续集成与部署等多个环节。合理分工、选择合适的工具和方法，以及培养对工作的热情，对于确保软件的质量和顺利发布至关重要。通过不断实践和优化，我们能够实现高效、稳定的软件开发和交付流程。