Travis CI 持续集成服务构建 Composer 类库简明教程

本文首发于 Travis CI 持续集成服务构建 Composer 类库简明教程，转载请注明出处！

在项目开发过程中，编码工作只是软件开发整个过程中的一小部分环节，更多的我们需要去构建和测试我们的项目，以确保项目的健壮和稳定性。

这篇文章将带领大家学习如何使用 Travis CI 持续集成服务和 Composer 中国包管理工具，来构建一个持续集成的 PHP 类库。

前期准备

进入正题之前，需要大家对以下几个工具已经有了初步的了解和使用经验：

Git: Git 是分布式版本控制系统；
Composer：Composer 是 PHP 项目的依赖管理工具，用于管理项目中的 packagies 和 libraries；
GitHub：是一个用于使用 Git 版本控制系统项目的共享虚拟主机服务，可以免费托管公开的源代码仓库。
Packagist：主要提供 Composer 包发布和索引，默认 Composer 从 Packagist 获取资源。

如果没有的话，最好还是先了解一下如何使用它们，下面让我们简单介绍一下创建相关服务账号的方法。

创建 Github 帐号

GitHub 是一个用于使用 Git 版本控制系统项目的共享虚拟主机服务，可以免费托管公开的源代码仓库。

本教程的基础就是基于 Git 和 GitHub 服务，所以需要我们创建 GitHub 帐号，并且 GitHub 官方提供 Packagist、Travis CI 的钩子服务。

当我们将本地的项目推送（push）到 Github 时，Packagist 和 TravisCI 服务会触发相关的钩子服务，去获取最新的代码。

如果没有账号的话赶紧去注册 GitHub 帐号吧！

创建 Packagist 帐号

Packagist 是 Composer 默认的包管理服务仓库，我们使用 Composer 安装（install）或引入（require）一个依赖包时，默认是从这里拉取依赖包的代码。

所以，开发 Composer 类库，需要使用我们的 Github 帐号授权并登录 Packagist 网站。

创建 TravisCI 帐号

Travis CI 提供的是持续集成服务（Continuous Integration，简称 CI）。它绑定 Github 上面的项目，只要有新的代码，就会自动抓取，然后提供一个运行环境，执行测试，完成自动化构建，它还能将项目部署到我们的应用服务器。这个教程主要讲解使用这个服务的测试和自动化构建功能。

在开始前让我们先完成以下准备工作：

首先，访问官方网站 Travis CI 使用 Github 授权登录。

然后，当授权登录成功后，点击右上角用户头像，这样 Travis CI 会获取到 Github 上你所有的版本库信息。

最后，选择你需要使用 TravisCI 服务帮你执行测试和构建的仓库，点击开启按钮。开启成功后，任何 GitHub 提交代码操作，都会触发 TravisCI 的钩子服务，然后执行测试和构建处理。

在完成以上帐号注册流程后，我们就可以进入到今天的正题，使用「使用 Travis CI 持续集成服务构建 Composer 类库」。

创建新的 Composer 类库

完成帐号创建及授权相关准备工作后，现在让我们就可以开始创建自己的 Composer 类库了。

在 GitHub 创建项目仓库

第一步需要到 GitHub 网站点击站点右上角加号（➕）创建一个新的项目仓库，这里我创建了一个名为 travis-composer-tutorial。

默认的 GitHub 会给我们创建一个空的项目目录，当然如果在创建时你选择了需要创建 .gitignore、开源协议和 readme 文件时，Github 还会给我们同时创建这些说明及配置文件。

将 GitHub 仓库克隆到本地

紧接着，进入到我们的本地的工作目录下，执行 git clone 命令将 GitHub 中的项目克隆到本地：

cd your_workspace_directory

git clone https://github.com/huliuqing/travis-composer-tutorial.git

请讲自己的工作目录及版本库的 URL 地址替换掉。

初始化 Composer 项目

初始化的目的是为我们新建的 travis-composer-tutorial 项目创建一个 composer.json 元数据文件。创建这个 JSON 配置文件有两种方式：

手动创建这个 composer.json 文件，文件格式可以参考库文档；
通过 composer init 命令行工具，采用交互式命令创建。

// 在 travis-composer-tutorial 项目根目录执行下面的命令

cd travis-composer-tutorial
composer init

引导初始化时需要我们创建以下几个初始配置选项：

Package name: 包的名称，我的是 phpzendo/travis-composer-tutorial；
Description []: 包的描述；
Author: 包的作者；
Package Type (e.g. library, project, metapackage, composer-plugin) []: 你开发的类库类型；
Minimum Stability: minimum-stability 字段的值；
License: 采用的开源协议；
require: 需要依赖的其它包，必须要有一个版本约束。并且应该遵循 foo/bar:1.0.0 这样的格式。

下面是我初始化 Composer 项目的交互截图，有一点需要说明由于当时网络原因并没有在初始化时添加依赖的其它包，后续我们可以使用 composer require 引入 PHPUnit 依赖：

通过 composer require 命令引入 PHPUnit 单元测试测试工具创建依赖。

composer require phpunit/phpunit

在这里引入 PHPUnit 的原因是我们的项目需要使用 Travis CI 服务进行持续集成和测试，当然你也可以替换成别的单元测试工具。

到这里，基本上我们就完成了一个创建初始 Composer 类库的功能。接下来，我们将进入到项目的编码阶段。

创建源目录

完成基本的注册和初始化工作后，才是进行项目编码阶段，在项目根目录下创建 src 文件夹。

项目的所有源码都会放置到 src 目录下，并采用 PSR4 自动加载规范来定义文件结构。

PSR 标准规范

PSR 是 PHP Standard Recommendations 的简写，由 PHP FIG 组织制定的 PHP 规范，是 PHP 开发的实践标准。

这里我们需要使用 PSR4 规范是最新的「自动加载」规范，它的功能是让 Composer 能够正确查找并加载我们项目的源文件。

使用 PSR4 规范定义文件的目录结构遵循以下原则：

\(\)*\

更多有关 PSR4 规范说明及使用可以查看说明。

编写模块代码

现在让我们来编写项目的首个模块吧。

作为教程，这里我们假设需要创建一个 Dumper 类用于替代 php 内置的 var_dump 输出功能。

到 src 目录下创建子目录 Dumper，同时创建 Dumper/Dumper.php 类文件。


 * @method mixed dump($expression, $title = null)
 * @license MIT
 */
class Dumper
{
    /**
     * 打印变量的相关信息
     *
     * @param mixed $expression
     * @param string|null $title
     * @return void
     */
    public function dump($expression, $title = null)
    {
        echo ($title ?: '调试：') . '';
        var_dump($expression);
        echo '';
    }
}

配置 Composer 自动加载元数据

编写完成我们的模块后，需要将项目目录配置到 composer.json 文件的 autoload 元数据中。

autoload 配置功能是定义 composer 自动加载与项目模块的映射关系，定义后 composer 才能正确查找项目模块自动引入类文件。

有关 autoload 使用说明可直接查看文档。

确认项目的命名空间。

我们模块的命名空间为 PhpZendo\Dumper\Dumper。

当前命名空间前缀为 PhpZendo 指向的是 src 目录，意味着 composer 自动加载会查找 src/Dumper/Dumper.php 文件并引入（require）。

将命名空间及文件引入关系添加到 autoload 配置

打开 *composer.json 文件并添加如下配置：

    "autoload": {
        "psr-4": {
            "PhpZendo\\": "src/"
        }
    }

更新 composer 依赖。

执行如下命令更新自动加载依赖关系：

composer dump-autoload

将项目推送到 GtiHub 并创建 Packagist 钩子服务

到这里我们基本上已经完成了开发一个简单的 composer 类库，现在我们可以将项目推送到 GitHub。

但是在推送之前，我们需要到 Packagist 官网配置 travis-composer-tutorial 项目的钩子服务。

将项目提交到 GitHub 远程仓库。

首先，确定是否有 .gitignore 文件，并确保 vendor 等目录不会添加到版本控制中。

我的 .gitignore 文件实在创建 GitHub 时自动创建的：

composer.phar
/vendor/

# Commit your application's lock file https://getcomposer.org/doc/01-basic-usage.md#commit-your-composer-lock-file-to-version-control
# You may choose to ignore a library lock file http://getcomposer.org/doc/02-libraries.md#lock-file
# composer.lock

推送项目到 GitHub。

git add *
git commit -m "Create travis and composer tutorial."
git push origin master

进入 Packagist 官网，点击网页右上角 Submit 按钮添加 GitHub 代码仓库地址。

进入页面后将 https://github.com/huliuqing/... 配置到 Submit package 表单，提交即可。

添加完成后我们的 GitHub 项目即添加到了 Packagist。

不过此时，我们的项目推送还不会自动在 Packagist 中完成任何代码推送的更新操作，而需要我们手动的去执行 update 操作才行，原因是当前还没有配置 GitHub 的钩子服务。

如何配置钩子服务，可以到说明文档去深入了解一下。

小结

在这一小节我们深入了解了如何创建 Github 版本库，使用 Composer 命令行工具初始化本地类库元数据信息；并且学习了如何定义项目自动加载配置和将 GitHub 版本库关联到 Packagist 站点。

下一节我们将讲解本文另外一个主题，使用 Travis CI 服务构建持续构建和测试项目。

支持 Travis CI 服务，创建可持续构建项目

Travis CI 提供一个运行环境，然后执行测试，完成构建，甚至还能将我们的项目部署到应用服务器。

要知道我们在编写软件时，编码仅仅是软件开发过程中一小部分工作内容；一个可靠的项目还需要对其进行测试，使用 Travis CI 这类持续构建服务，可以简化测试工作并保证项目的质量。

这一节将学习持续构建相关知识。

创建 PHPUnit 单元测试用例

PHPUnit 是 xUnit 单元测试类库家族中的一员，使用 PHPUnit 的一个主要目的是为我们的模块创建单元测试用例。

在项目中，究竟何时才需要使用单元测试技术呢？

一个很简单的判断标准就是，当你想在项目中使用类似 var_dump 函数打印输出内容时，一个更好的方式就是将输出替换成单元测试。

创建 tests 目录

让我们在项目的根目录下创建 tests 文件夹，之后我们所有的测试用例都会放置到这个目录中。

编写 PHPUnit 测试

接下来需要编写 PHPUnit 测试用例，如何编写一个简单的测试用里遵循以下规则：

针对类 Class 的测试写在类 ClassTest中；

ClassTest（通常）继承自 PHPUnitFrameworkTestCase；

测试都是命名为 test* 的公用方法。

更详细内容可以查看 PHPUnit 中文网文档说明。

所以这里我们创建一个 DumperTest.php 单元测试用例，并将这个测试用例创建在 tests/unit/DumperTest.php 路径下：


 */
class DumperTest extends TestCase
{
    /**
     * 测试 Dumper 类实例化
     *
     * @return void
     */
    public function testDumper()
    {
        $dumper = new \PhpZendo\Dumper\Dumper();

        $this->assertInstanceOf(\PhpZendo\Dumper\Dumper::class, $dumper);
    }
}

这个测试用例主要用于检测是否成功创建 Dumper 类。

执行单个测试用例

完成测试用例编码工作后，我们需要验证测试是否通过。之前，我们的项目已经引入了 phpunit 依赖，所以这里我们可以通过下面的命令去执行测试脚本：

./vendor/bin/phpunit UnitTest ./tests/Unit/DumperTest.php

以下是执行结果：

有关 PHPUnit 命令行工具可以查看命令行测试执行器相关文档。

虽然，我们现在能够成功执行测试脚本，但是如果我们的测试用例有多个的话，这样一个一个写出每个测试文件似乎有点傻乎乎。

有没有好的解决方案可以将所有 tests/unit 目录下的测试文件都执行测试呢？

接下来会交大家如何编写 PHPUnit 测试 XML 配置文件。

编写 PHPUnit 测试 XML 配置文件

很多时候我们的测试脚本并非只有一个测试文件，而是会有许多的测试用例，这种情况下需要使用 XML 配置文件来帮助我们的 PHPunit 找到所有这些测试文件路径。

下面是我编写的 phpunit.xml 配置文件信息：


    
        
            tests/Unit

其中我们需要重点关注以下几个属性功能：

配置文件包含一个属性，作用是用于配置 PHPUnit 的核心功能，其中 bootstrap 属性用于设置自动加载文件路径；
phpunit 包含一个或多个，作用是用于将测试套件及测试用例组合出新的测试套件；
用于配置测试用例目录。

随后，我们可以通过下面的 phpunit 命令行工具从 XML 文件中读取配置并执行测试：

./vendor/bin/phpunit -c phpunit.xml

配置 Travis CI 服务

到这里说明我们的项目进行的非常顺利，接下来就是需要到 Travis CI 配置 GitHub 项目的钩子服务，并执行自动化测试。

Travis CI 官网开启项目的钩子服务

如果测试一切顺利的话我们就可以进行下一步，到 Travis CI 官网去开启 travis-composer-tutorial （这里请开启自己的项目）项目的钩子服务，如何开启可以到「创建 TravisCI 帐号」以及查看。

配置完成后可以看到看到 Travis CI 网站会获取到我们的项目

编写 YAML Travis CI 测试配置

Travis 服务提供多种编程语言的自动化测试支持，所有这里我们需要编写 PHP 语言的测试配置。

Travis CI 配置文件使用 YAML 语言编写，配置文件名为 .travis.yml。有关配置的具体细节可以到 Building a PHP project 去了解。

下面介绍我们的教程需要完成的一些配置信息：

language: php

php:
  - 7.1
  - 7.2

before_script:
  - composer install

script: ./vendor/bin/phpunit -c phpunit.xml

language 和 php： language 用于配置项目采用的编程语言； php 用于指出当项目使用 PHP 开发时选择使用的 PHP 版本，这里我们使用 7.1 和 7.2 版本；
before_script: 用于在执行 script 脚本前，需要执行相关操作，我们这里去执行 composer install 操作安装相关依赖；
script：用于配置我们需要执行的脚本，Travis CI 默认会使用 PHPUnit 作为单元测试工具，并运行 ./vendor/bin/phpunit -c phpunit.xml 进行单元测试。

在我们的配置中，可以将 script 配置简写成：./vendor/bin/phpunit。

提交代码到 GitHub

git add *
git commit -m "Support travis ci and phpunit test."
git push origin master

推送到 GitHub 会触发 Travis CI 的钩子服务，并在 Travis CI 执行自动化测试和构建服务。

下面是 Travis CI 自动构建结果：

总结

以上就是今天的主要内容，希望对大家有所帮助。

参考资料

持续集成服务 Travis CI 教程
Composer 入门
使用 GitHub、Composer、Packagist 管理公开的 PHP 包（Step By Step）
Git 教程
TravisCI 文档
如何简单入门使用 Travis-CI 持续集成
学习开发自己的 Composer 包，并使用 GitHub 实时更新到 Packagist
YAML 语言教程