贵司发布一次代码需要多长时间？

1 分钟内，Rails

jenkins node 项目大部分不超过一分钟，基本全是 api，可以提升，但是没必要。

发布不需要多久，擦屁股擦了几天罢了。

4 个工程师，电商，php，git pull，30 秒左右。
其实在生产环境不应该用 git pull 这种形式发布。

话说 web 项目, 比如 Python,发布新版本的时候会有一小段时间 404,这个怎么避免？

@liuzhedash 请问有什么弊端呢

@JasperYanky #5 可以启动多个 server，发布前先把 nginx 指向其中的几个，更新剩下的，新版本启动并且没问题的话，nginx 指过去再更新剩下的……

@MarcoQin 666

@holyghost #6
生产环境里面不应该有代码库的信息

跑完测试，git 获取更新，更新数据库，重启应用，都写在一个脚本里面，30s 搞定！

AWS elastic beanstalk docker 部署至少 30 分钟

@liuzhedash #4 请问生产环境怎么发布？

jenkins 发布，生产机器很多，不出问题 30 分钟发版完，但是发布完之后测试做回归测试几乎要 2 个小时内做完（有时候更久）。
因为是串行发布，有时候脚本跑好几个小时的情况。

编译，测试，报告 ==> 1~2 小时
QA 确认 ==> 30 分钟+（确认后按下 Confrim 按钮）
部署 ==> 15 分钟

2 周吧，编译，上传 app store，苹果审核

代码都是小事 如果涉及到 数据库的 schema 变动 并且是有冲突的 比如把某个字段变类型 我很好奇这种一般怎么做 有多块

@jyf 我遇到的情况是给数据库做 migratino。
1.给数据库定义 version
2.写出每个 version 间的变动，比如 1up2 的 migration 是 aaaaaaa, 2down1 的 migration 是 bbbbbbbbb
3.跨越多个 version 的变动就执行当中所有的，比如 1->5= 1->2,2->3, 3->4, 4->5

不知道有没有更巧妙的办法。。。

到底生产环境怎么部署新版本程序最优雅？

感觉 git 是肯定不能用在生产环境的（无论是 clone 还是 pull ）

芯片公司 sdk 发布 基于 android.
>一月一次

docker compose!

git pull 发布机 剩下的 rsync --exclude=/.git

java ,jenkins , 2 分钟的样子.

5 人小团队，电商 o2o，java ssm，jenkins，三周，android iOS 上线，

Rails + Capstrino 一键发布 ，1 分钟之内吧

docker + k8s 1 分钟内吧

Rails + Mina + Puma, rolling restart 解决发布期间当机的问题。migration 解决数据库修改的问题

Deis, git push staging / git push production 发布，Javascript 预处理比较久，5 分钟吧。

我也想知道为何不能用 git pull 直接更新

用 jenkins 生成 docker image 作为 artifact，推到 docker hub，ecs 再 pull 下来，自己进行蓝绿部署。大概 5 分钟。

Java 技术栈，后台大概要 24 小时左右，全球按时区划分，在每个时区凌晨的时候部署重启应用。
前台很快一般 1 小时以内可以搞定，主要是 CDN 更新需要时间。

五分钟

@MarcoQin 我们生产也用的这种策略....再配合 docker...感觉爽爽的

@nikoo
@liuzhedash 为什么生产用 git 不好?

@MarcoQin 这个就是灰度发布的意思吗？

xx 万机器 Agent，基本一个月才能升级一轮

现在已离职一个多月，个人项目一般直接用 ansible, 30s 左右可并行发布到多个环境。

说说以前的情况，3-5 人开发团队，一开始自动化工具都没有，引入 Jenkins 后有过几次改进：
- 最初自动化部署 API （ Python ）、Web （ React ）项目，一般 5min 左右
- 因代码托管在 Github 上，服务器在国内，build 经常超时，增加一台 HK 服务器做 Jenkins Slave，时间减少到 1min 内
- 增加 docker 部署后，使用 daocloud 加速，一般耗时也可以维持在 1min 左右

React 项目得看更新情况，cnpm 不一定好用，网络也不一定好，可改进空间还是挺大的。

传统通信公司，专网设备开发，全国大概有 8000+人吧，对内发布的大概 2 周一次，对外发布的大概 3 ～ 6 月一次，看升级需求。

@dylanninin ansible 赞

较为固定的是 2 个月一次，临时加急的临时搞，大约一周吧。升级固定在周五晚。两个月一次的大升级要组织多个部门在升级后的生产环境进行测试。临时搞的要提前在验证环境测完并提交测试报告并把内容全部打包好。如果是上级部门组织的全网测试，事情就更多了，要进行 N 轮，持续个把月，然后才能发布。

@liuzhedash 居然还有人在生产环境 git pull 的呀。。。

秀个我司 PHP+Node.js，N 多微服务：

@lightening 你们用的什么框架居然要 5 分钟之久？我们最长的也就 2 分钟左右。


@jyf
@vjnjc migration +1 自从用了 migrations 脚本，再也不怕 N 多环境之间数据库的结构同步问题了。。。特别是对于有 N 多从库的情况。

@Clarencep #40 刚开始转 git 的时候，这是 git@oschina 推荐的的做法，刚刚又看了一下已经不推荐这么做了，想来是终于有人意识到了问题

3 年

@Clarencep
@liuzhedash git 用在生产环境有什么问题?
这个贴有 4 个人这么说了,谁能列一下相关的坏处呢?

@clino #44
1、生产环境不应该有代码库的信息，比如你每次的 commit 都会在.git 下面，这些存储空间的占用是没有意义的
2、生产环境可能不能连接到代码库

@liuzhedash 如果仅仅是以上两点，我认为并没有充分的理由拒绝在正式环境用 git pull 部署，首先第一点，commit 的存储绝对不会过大，而目前廉价的硬盘，足以让你忽略这点占用，第二点，就更不需要担心了，可以通过运维手段解决。

@vjnjc 你们碰到过原来某字段是 int 现在变成 varchar 这种情况么 按这种 你的 migration 怎么写呢

@liuzhedash 生产环境 build docker 镜像，git pull 完了以后删除 .git 资料库文件，然后再上传镜像，这样应该是 OK 的吧

@jyf 只会加字段，不会改类型

@liuzhedash
- "生产环境不应该有代码库的信息",我觉得如果是 python 这类直接用源代码运行的应该有,因为万一有时候有问题直接现场就能看出代码是在哪个版本上,生产环境的代码有没有被碰过
- "些存储空间的占用是没有意义的" 同上,我认为是有意义的,当然前提是用源代码运行的这种,不是那种编译出二进制运行的
- "生产环境可能不能连接到代码库" 如果能连那么这点是不是就不是理由了?

@haozxuan001 #46
是的，其实这些不是决定性的理由，但是确实是存在的问题

@kosilence #48
既然都用 docker 部署了，其实和 git 已经没什么关系了

git pull

pm2 restart all

原来你们的代码不用编译直接就拿去跑了

@liuzhedash 即使用 docker 也一样可以用 git,我们有这样的用法,需要版本控制的部分是映射目录到 docker 里面的

@dingsoung 动态脚本语言哪个不是这样?

@clino git pull 的方式部署我以前也用过，发现会有一些问题，后来才切换到 jenkins + rsync 的方式：

1. 生产环境上并不一定是所有文件都是在 git 中，git pull 并不能把所有文件拉上去（比如 node_modules 文件夹、vendor 文件夹，而在生成环境执行 npm install/composer install 又比较好资源影响正常业务运行，还不太稳定）
2. 有的时候会临时在生产环境上改个东西，要是忘记恢复了的话，git pull 会失败 (/ □ \)
3. git 是搭在内网，而生产服务器是在云上，网络不好打通（而且把 git 服务器暴露在公网上有安全风险）

@Clarencep
1 这个就要具体看业务是怎样的,所以 git 是不是适合不能一概而论
2 我怎么觉得这是一个好处呢?
3 有一个 workaround 方法是先 push 到生产环境下的一个 bare git,然后生产环境的 git 是从这个 bare clone 出来的,这样 push 完这个 bare 以后再 pull 就行了

@holyghost 如果是使用这种方式的话，你访问一下网站目录.git/config，就能看到 git 的欣欣，基于此之上，可以吧 git 相关的元数据全部拉回来，然后 reset 一下得到最新版本的代码。参加之前一个朋友做的小工具 GitHack

@clino
@Clarencep

@holyghost @clino @Clarencep
这暴露出来的是安全问题，在部署上这没有任何问题，在 webserver 上是可以访问到.git 文件夹的，里面的东西也能访问到，如果了解 git 的工作原理的话，有了.git 这整个文件夹也就意味着有了整个代码库，对于线上版本来说代码库里泄露的东西太多了，诸如数据库连接信息（阿里云 RDS 是可以直接远程连接的，除非你设置了白名单 IP，然而大部分人都不管），代码逻辑等等，如果有心人基于此做代码审计发现漏洞然后加以利用，嗯你懂得。我在安全行业生涯中有过这样的案例，入口点就是一个 git 信息泄露，最终渗透到了服务器层。个人感觉安全意识还是蛮重要的一件事

git co > cp to temp dir > npm i > webpack > gz pack > download > kill nginx > kill node > rm original code > unpack new code > start node > start nginx 大概 3-5 分钟吧

@yw9381 前面有 nginx rewrite，访问就是 500，靴靴。

@yw9381 有点道理,不过呢这说明都能直接访问到生产环境了吧?这个不要加上.git 信息事情就已经很大条了...

@yw9381 数据库连接的账户信息还有各种 key 当然不能放 git 里面。果断应该用进程的环境变量或者.env 之类的来保存。

个人感觉 jekins 没 teamcity 好用，不知道为什么用的公司那么多。看到 jekins 那界面就恶心。

@bk201 因为不要钱啊。。。免费的 TeamCity 只能 20 个配置，除非特别小的项目，不然基本不够用。

@bk201 teamcity 太大

jvm 应用 基于 kubernetes 带健康检查,3-5 分钟稳定发完

@holyghost 我不是特指的贵司的系统，有些会在发布以后在 webserver 层面做处理，然而大部分的情况是，能用就行，完全不怎么管，我个人感觉你对贵司的系统很自信啊，天下没有攻无不克的矛，也没有战无不胜的盾，安全很多时候都是死在蜜汁自信上（大部分 ZF 里面就是，我们是纯内网，他们怎么可能进来，结果 WannaCry 出来以后是真的哭了）。
@clino 生产环境本来就是在公网上的，谁都能访问，对于生产环境可以在 webserver 上做目录限制，或者在重写规则里写上限制，如果你不作处理那真的谁都能访问到的。
@Clarencep 如果能放在.env 里最好不过了，不过有时候一不注意就 git add ./ 或是某个人没这个意识，一直在 add ./ 然后 commit 上去，从此在仓库里留下浓重的一笔，这些信息一般情况下很少会去改吧。进程环境变量在代码里也总要有个初始化的地方，这个地方和传统的 db.config.php(DBHOST，DBUSER，DBPASS，DBNAME)这种没区别，正儿八经的解决是在客户端这里的. gitignore 里设置忽略，在 webserver 上设置权限。安全是个木桶效应问题，所以每一个点都是要顾忌到的

@Clarencep 后端 Rails，前端一部分 Angular 一部分 React/Redux。Angular 是以前的代码，是用 Rails 的 assets pipeline 打包的，比较慢。React 部分用 Webpack 打包，挺快的。正在全面迁移到 React，让后打算拆掉 Angular。

@yw9381 这样的话不用 git 不是也能访问到整个当前的代码库啦？

@wohenyingyu02 夸张，审核大概两到五天，正常更新的是第二天审核玩，迟点三天，新上架的却审核时间长，估计一审二审的，前几年的却满，现在飞快 [虽然不是秒级]

前几年审核发布那叫一个漫长

你们测试都不需要回归的啊。。。

@yw9381 我就说我们的情况吧,我们一般是用 uwsgi 跑 python 应用,然后反代到 nginx,这种情况下有没有.git 在 web 服务上是没差别的,并没有直接开通相关目录的静态文件
所以我完全没想到你说的这种情况

我怎么觉得 rails 的哥们这么多呢

PHP git webhook 代码文件变动都是从出文本变动也就是个传输时间，一般 10 秒左右……

真羡慕你们，真想打一顿我司那群用 war 包的余孽

make jar not war

@clino 同样 nginx+uwsgi+django 根本不会出现.git 目录泄露的问题

@yw9381 那你们.env 里面的信息记录在哪

@liuzhedash 应该用什么方式发布更合理？

@chiu 什么公司，还专网

@l32606 可能专网这个概念比较冷门吧。相对于我们平时打电话用的公网，公安，消防，政府或军队等应急通信场景用的网络是专网

@rannnn 前台是用类 php 之类更新不用重启的语言吗？

56 个 docker 发布 php，耗时 1 个多小时。还不能对某个文件升级，需要重做整个镜像

@yw9381 .env 当然要加到.gitignore 中。此外生产环境上的.env 文件要配置下权限，www 帐号只有只读权限，其他帐号都没有权限访问。


@welling php 发布用 docker 太重了点吧。完全牺牲了 PHP 可以随时热部署的优点。


@lightening Angular 打包原来这么慢呀。。。还好我们用的是 React/Preact/Vue

@clino django 的 uwsgi 反带过去倒没有这种问题，因为静态目录不能直接访问到 /.git/元信息

@lightening 访问到当前代码库的前提是在浏览器上能够访问到.git 文件夹，能够访问到 git 的元信息，这在 php 中很常见，py，nodejs 的我不是很清楚，写的不多。

@zonghua env 本来就记录他原本该记录的东西就好了啊，生产和测试配置不同的信息就行。

@Clarencep 老铁没毛病~

其实 git 信息泄露这种情况还是多见于自己裸写开发的东西，如果是上了框架，例如 php 的 TP 或是 laravel，因为有 URL 路由及重写规则来处理，反而很少遇到这种情况。

@Clarencep 敏感信息（数据库密码等）可以考虑用一个单独的 Vault，Java 的话 Spring Cloud 已经支持。

脚本手工操作的路过

@yw9381 Python, Ruby ,Node 一般都不会这样。我的意思是，如果能从 web 访问源代码目录的话，即使你删了 .git 目录，当前版本的源代码不是还能被发现？

@FanError 前台就是静态的 Javascript 嘛

我们用的 Bamboo

@hantsy 哦，Vault 是神马呀？没有用过。

@lightening 线上是在对应环境上正在运行的代码，你直接访问的话代码是会正常运行的，php/py/ruby/node 基本上都是，不存在会直接看到源代码的可能，代码总归还是要部署到对应环境才能跑起来的，但是.git 这个目录原本就不属于代码，所以对应代码的解释器不会管这些，在 webserver 这里如果不做处理的话，会把这些当成普通的资源文件返回给客户端，也就造成了 git 信息泄露的问题。

@precisi0nux 同, 如果加上跑测试的时间可能 10 分钟才能完成部署. 不同的是我没有做蓝绿,因为要人工参与,后期如果换成负载均衡就不需要手动蓝绿了.

@yw9381

Ruby、Python、Node 都不是把源代码放在 HTTP server 根目录访问的，所以没有这个问题。以 Ruby 为例，是启动一个 Ruby 进程，然后接管 HTTP 请求。

据我所知只有 php 是把源代码放在 HTTP server 根目录下，然后直接用浏览器访问 .php 文件时，Apache/Nginx 会用 php 解释器去执行那个 .php 文件。我想问，如果这个目录下还有个属于源代码一部分的非 .php 文件比如 foo.bar，是不是可以直接通过 /foo.bar 访问到？

@lightening php 毕竟是为了 web 而生的语言，其他的语言基本都是因为有需求所以才支持的 web 开发。php 的解释器要么 apache-mod，要么 php-fpm，不管哪个，如果没有路由没有重写规则，几乎就和 ftp 一样了，对于你说的 foo.bar,是肯定可以访问到的，如果没有对应的处理，就完全当文本文件返回来了，

@yw9381 对啊，所以如果不自己配置 HTTP server 规则，即使没有 .git 目录也有其他的安全隐患。

暴露.git 肯定是不行的，连.git 都暴露了，.env 还远吗？

有些 PHP 框架、应用的入口 index.php 还真是在项目的根目录，然后同一级的.git 就很容易暴露了。

现在在阿里云的容器服务，重新部署大约 1 分钟。