资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/使用 Satis 搭建私有仓库

使用 Satis 搭建私有仓库

gityuan / 3017人阅读

摘要：此时我们就需要一个工具，能够搭建私有源，里面都是私有仓库，对内不对外。就是官方提供的建立私有源的工具。在其它项目中使用私有源只需要在项目的文件的根上添加仓库地址之后再通过或者想要的仓库就可以了。

现在我们常用 Composer 进行依赖管理。和其它语言的包管理工具一样，Composer 使用 GitHub 托管代码，可以根据配置文件管理依赖，也可以建立各种脚本，执行特定任务。总之好处很多。

实际工作中，我们可以把多个项目公用的逻辑抽出来，作为一个依赖，然后提交到 Packagist，就可以在其它项目中引用它了。但是，与 NPM 这种工具不同的是，PHP 程序多半会部署在服务器上，通过接口接受外部访问，对安全性的要求高很多。前端可以放开给大家随便观摩，后端最好还是放在别人轻易看不到的地方，万一哪个同事把密码、salt 写到代码里提交，被搜出来，结果可能就很危险。

此时我们就需要一个工具，能够搭建私有源，里面都是私有仓库，对内不对外。

Satis 就是 Composer 官方提供的建立私有源的工具。它的文档在这里 以及 这里。

整体流程并不复杂，文档里都有，我简单复述一下，只包含我用过的部分，重点穿插我的经验。我假定读者已经了解 Composer 的基础使用，如有问题，请自行翻阅文档。

1. 建立项目

使用 Composer 自带的建项目功能，这个相当于 git clone + composer install + 运行 post-install 脚本。

composer create-project composer/satis my-satis --stability=dev --keep-vcs
2. 建立配置文件

在 /path/to/my-satis 目录下建立 satis.json 文件

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require-all": true
}
注意：仓库名称需要和仓库里 composer.json 的 name 定义一致，和路径没什么关系，不然就会找不到。我当时被这个卡了好久……

因为加入私有源的仓库本身可能也有依赖，require-all 会把这些依赖的信息也抓进来。如果不需要的话，可以指定某个仓库，甚至某个版本：

{
  "name": "仓库名称",
  "homepage": "http://satis仓库地址/",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo" },
    { "type": "vcs", "url": "http://svn.example.org/private/repo" },
    { "type": "vcs", "url": "https://github.com/mycompany/privaterepo2" }
  ],
  "require": {
    "company/package": "*",
    "company/package2": "*",
    "company/package3": "2.0.0"
  }
}
3. 生成仓库列表

执行

php bin/satis build satis.json ./web

就可以在 path/to/my-satis/web/ 里生成仓库列表了。

4. 在其它项目中使用私有源

只需要在项目的 composer.json 文件的根上添加

{
  "repositories": [
    {
      "type": "composer",
      "url": "http://satis仓库地址/"
    }
  ],
  "require": {
    "company/package": "1.2.0",
    "company/package2": "1.5.2",
    "company/package3": "dev-master"
  }
}

之后再通过 composer require 或者 composer install 想要的仓库就可以了。

注意：源里面只有“仓库列表”，并没有真的同步代码仓库过来，所以下载还要走托管代码的机器，比如 GitHub，内部 GitLab 等。所以需要确保相关的 ssh-key 已经添加，或者在配置文件中写上登录信息（不建议这么做）。
Tips: secure-http

satis 默认要求使用 https，不过 https 需要证书，不太好搞，比如前司运维就不愿意弄（当然，他们工作很忙，我十分理解）。此时我们可以设置 secure-http 为 false 强制 Composer 接受 http 的源。需要注意，secure-http 是 config 的属性之一，写在根上是没用的。

{
  "config": {
    "secure-http": false
  }
}

总结，Satis 私有源的搭建，对于使用 PHP 的开发团队来说是非常必要的。用 Composer 管理依赖效果也非常好，希望所有 PHP 开发者都好好学一学。我现在用的也比较浅，将来有心得继续补充。

题外话

再聊一些题外话。PHP 是个很好的语言，简洁高效，易学强大。但是出身不好，工程学上的高起点反而成为大家轻视它的原因。很多开发者也的确对自己要求不高，只写业务逻辑不考虑语言特性，使得代码难看难改难维护。所以我想多说两句回顾一下 PHP 本身的发展史。（以下以我个人经历为主）

上古时期

我们一个页面写一段 PHP，或者一个动作写一个 PHP，收集请求，做出处理，给出回应，完成。

好处：

简单，好上手

逻辑关系清晰，从前端可以直接找到目标程序

一个地方出错，多半只挂一个功能

坏处：

代码复用率低，不好维护

难以批量修改

古典社会

随着工程变大，需要大量的 PHP，分散碎片化的代码实在难以管理和维护。于是我们开始把一些共用代码抽出来，做成一个函数，叫 functions.php，其他所有页面都 include 它，这样公用的代码就不会这里一份那里一份了。

好处：

提高了代码复用性，减少开发量，提升效率，降低维护难度

坏处：

工程大的话，一个 functions.php 好几千行，可读性也没好到哪儿去

有时候我们需要对一个函数进行一些小修改，于是不仅函数库会膨胀，函数本身也在膨胀

中世纪

PHP 引入类的概念，并且提供了“魔术方法”来实现一些功能。有些程序员也意识到不能所有代码都自己手写，该引用的还得引用，于是从一些开源的库拷来代码开始用。这个时候连 Google Code 都不存在，下载代码多半在网上搜索 + Ctrl C/V，所以代码中各种混用。经常出现，我 include 一个文件，然后就挂了，原来是类被重复定义，或者全局环境下同名函数互相覆盖。开发乱象不断，形如黑暗的中世纪。

好处：

不考虑维护的话，开发速度还是可以的……

坏处：

越到后来坑越多，项目一大积重难返

内部执行环境不统一，a.php b.php 的内部环境都不一致，共享代码反而更加困难

文艺复兴

PHP 对类的支持已经十分完善了，大家也开始习惯用命名空间划分领域。通过使用设计模式、继承、接口，复写功能和代码管理的情况大大改善。同时，伴随 Google Code 和 GitHub 的出现和发展，大家有了一个托管代码和寻找代码的好地方。我们也开始用 SVN 管理代码，不会再搞出 action.php action.php.bak action_new.php action_new.20160102.php 这样的幺蛾子。开始学习开发规范，开始更多的的用类管理代码。

好处：

代码规范

版本管理后，更好追溯代码的变更记录

可以下载到新版本的代码

坏处：

SVN 不方便进行多仓库的管理

测试还靠人工发掘问题

近代社会

Git 开始普及，我们可以更方便的管理代码了。GitHub 发展速度很快，从上面找好代码也很容易，凭借 Git 子仓库的概念，维护依赖也容易很多。MVC 框架开始普及，单入口开始流行，内部执行环境得到统一。开发者意识到测试的重要性，开始使用测试工具进行测试开发，代码的稳定性进一步提升。

好处：

内部执行环境统一，全局修改变得容易

开始写测试了

坏处：

学习成本开始增加，新入行的人开始搞不懂，为啥写一个脚本就能干的事，你们要搞这么复杂一套架构出来

现代社会

包管理工具成为标配。项目依赖不再通过复制代码或者子仓库来管理，而是直接使用包管理工具 Compposer。并且整合测试、部署脚本，方便我们更容易地完成整套开发流程。另一方面，前端之前已经崛起，PHP 可以更多的考虑后端业务逻辑，输出纯粹的数据接口。

好处：

大型项目稳定性可用性大大增加

专业分工加强，PHP 程序员可以更多考虑后端逻辑

坏处：

学习曲线更加陡峭，新人入行更难，甚至连有经验的老人都未必能适应新形态的开发。

然则历史的车轮不可阻挡，我们势必会走向学习成本更高、学习曲线更陡，但业务量更大、更稳定的未来。

与我的博客同步更新。

云服务器 GPU云服务器 私有仓库搭建 Satis 私有镜像仓库 码云私有仓库

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/22148.html

相关文章

  • 使用 Satis 搭建私有的 Composer 包仓库

    摘要：说明服务器环境代码管理平台码云文章中尽量以一个真实的情况来撰写，但是文章的仓库地址，网页地址均是不可访问的，用虚拟信息替换了真实信息。比如码云，是收费的，对于一个公司来说费用不高，但是加上以上两点原因后，所以未选择。 简述 iBrand 产品立项时是商业性质的项目，但是在搭建架构时考虑后续的通用性，因此每个模块都设计成一个 Package，作为公司内部用，因此这些包并不能提交到 pac...

    lovXin 评论0 收藏0

  • composer私有仓库搭建

    摘要：安装包添加配置文件添加类似如下内容配置文件详解仓库名字主页地址包所在地址指定获取哪些包及对应的版本，获取所有包使用，与包中中的名称相同，不同会出现问题必需要的，表示生成的压缩包存放的目录，会在时的目录中压缩包格式默认和 安装satis包 cd /home/wwwroot/ composer create-project composer/satis --stability=dev -...

    h9911 评论0 收藏0

  • 使用 satis 搭建 composer 本地仓库

    摘要：如果需要定时更新，则需要配置定时任务去定时更新设置本地仓库设置虚拟主机使用本地仓库中的包文件中添加以下拉取，即可获取本地库了如果本地仓库不存在且有网络会去网络中获取。 环境 windows nginx php composer 安装 拉取 satis 项目包，并拉取项目依赖 composer create-project composer/satis --stability=de...

    张率功 评论0 收藏0

  • 使用satis自建私有镜像

    摘要：假设同一个包有多个开发人员则将其他人员设置为组成员，在同一台跳板机上部署项目，并且设置项目的为。这样在开发环境中通过登陆来判断权限。在跳板机上则通过添加该机器的公钥到来判断权限这样就算其他人有仓库地址也不能拉到代码，目的基本达成。 建立目的 为了不让代码公开，能够让项目基于gitlab快速自动化部署，简化单个composer.json文件配置内容 安装 使用composer compo...

    lscho 评论0 收藏0

  • 这两年多我写PHP业务代码的方式是如何进化的

    摘要：曾今谁都有过迷茫期，下面是我开始开发中，不断改变的代码组织方式。 曾今 谁都有过迷茫期，下面是我开始PHP开发中，不断改变的代码组织方式。 初期：所有代码一股脑控制器controller 曾今只是简单的理解MVC 中期：业务代码抽象一部分到模型层model 开始觉得model层是否该做点什么了 后期：业务代码控制器，模型层只写db的curd方法 复杂的业务代码使contro...

    qqlcbb 评论0 收藏0

发表评论

登陆后可评论

0条评论

gityuan

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<