想了解一下, 一般来说, 线上服务器环境部署是由运维来做还是研发?

1、试试 docker
2、理论上研发输出应该包含线上部署指导书

此时 docker 的价值就体现出来了

我们是开发提交依赖管理文件

运维部属时跟代码一同部属

大公司运维来做，中小公司研发+运维

小公司不都是开发“顺便”解决掉这个问题么？

之前待的公司后台要我把服务器换成 win7 试试你能信？

要是线上部署都是研发来做。。运维还能做啥呢？只能搬搬服务器，修修网络了吧。哦，对，现在都用云了，那就下岗了 ：（

流程细的公司，研发出文档，运维操作，流程一般的公司，研发和运维蹲角落一起搞，没有流程的公司研发自己搞。

运维呀，开发写一份部署文档给运维，必要时协作部署。

你们不用自动化部署嘛？ CD CI

你们都说用 docker，在我相处过的公司里绝对不允许用 docker，因为有性能损失，别和我说损失很小，损失就是损失，不在乎多少。

我们这里，包括打扫机房，都是我。
其他时间是躲在售票机里，给你们出火车票。

@shadowwalker2644 CI CD 也要写脚本啊，脚本谁写呢?

@gdtv 相同的情况，而且 docker 只适用于无状态服务。docker 打包也不是一件轻松的事情，一般研发不太愿意做的。

@gdtv 任何事情都是有代价的。

如果一个技术带来的收益，超过带来的缺点和问题的成本，那么就是可以考虑的。

每个项目、每个人所衡量的收益、成本不同，没必要拿来作为唯一准则。

开发写部署脚本

@gdtv 一样的看法，前阵子研发的老大说想上 docker，被我委婉的拒绝了。docker 的场景没大家想的那么大那么好，现在很多人是惯性思维，有事没事装个 nginx 都要给你 docker 一下，问题是意义在哪，估计他自己都不知道。

@FFLY 现在 IT 技术圈浮躁的东西太多了，一拥而上，结果发现其实并没有什么卵用。就好比现在什么平台都号称是人工智能的一样。

开发提供需求列表，DevOps 写进部署脚本。

机器数量没上规模，别 docker 了。
楼主能问这种问题，还是自己搬小板凳进机房装了就行了。

@tabris17 开发一般不了解生产环境的详细架构情况的，部署脚本里的相关参数修改，高可用什么的没办法写吧。而且部署脚本写得好也不是一件容易的事情。。

@lincolnhuang 是的，跟风得太多了。很多时候都是频繁听到某个新名词，然后百度一下，拍着脑袋就说我们也要上这个新技术。

@lincolnhuang 像我们这种集开发运维测试 QA 于一身的程序员，只有自己写的命。回答楼主，我觉得应该是开发写比较好，不然你都不知道运维把你代码怎么糊弄上去，出了问题还得找你

@FFLY docker 目前问题还是挺多的，虽然我们公司推了 docker 的云服务，但另一方面也在强调 severless 架构

小公司, 研发没给任何文档, 只有"所需软件<===>版本号", 研发团队异地, 实时沟通不太方便, 继续填坑 ing...

我们一般是开发（也就是我们）写个大致的部署方案，比如某文件要和某文件一个目录，某某某要放在某某某下面之类的。然后运维根据实际情况去操作。让我们写完整的部署脚本？我连生产环境有几个机器都不清楚，怎么写……

@lincolnhuang 运维要做日常监控，设置 alarm，一旦出问题要第一时间排查处理

@tuding 我觉得楼主得提供一些具体信息，服务器架构是在云端还是自建机房。如果是后者，研发可能是不容易部署的。前者的话借助 ci cd 工具，只要一开始设置好，以后每次 push 立马 build test deploy。迭代效率非常高，老板开心，你也开心

新生事物在早期本身就是有很多问题的，Docker 确实解决不了所有问题，有自身的缺点，也会带来新的问题，不过搞软件工程应该知道的第一件事不就是“没有银弹”吗？

在技术未完全成熟时无脑拒绝和无脑跟风本质是一样的，提早作出判断收益才会更大，否则等着别人直接把你换掉 \_(ツ)_/？

那些高大上的企业的容器实践分享可是实际存在的，自私的讲，出于丰富自身技术阅历考虑，也得尝试一下吧？

没有银弹+1

测试做，测试除了不开发业务代码，能干的都得干

谁会谁干

现在都上云了，谁还要运维？

@0x8C 上云了就不要运维了？神理论！

@FFLY 上云了，确实可以不要运维了，这种工具还是需要的 https://xabcloud.com

@ywgx 所以你对运维的认识就是偏的

线上的肯定运维来做（ CI/CD ），研发出文档并做好支持

要是没有 LVS 技术，docker 部署在物理机上，就是革命性的应用。现在的云服务器都是基于计算池虚拟出来的，身就可以热拔插，docker 的神功失色了不少。

脚本+ssh 解决大多数创业公司问题。

@FFLY 确实低级的运维不需要了

iaas 环境下运维来建设和维护线上环境。容器环境的化由于 docker image 很好的包含了程序的运行环境所以运维可以不关心这些。这样同时解放了运维和开发。再也不会因为环境不一致问题导致运维和开发相互丢锅。有问题就只会是开发的锅

@tomczhen 笑出声~2333

肯定是运维来处理啊，不然要运维来干嘛

小公司，两个开发，谁没事谁部署

对版本有要求这种事，一定要坚决打击

docker 有三种用法：
1 当虚拟机用，长期运行
2 不懂行的研发塞一堆垃圾进去，反正外边也看不见
3 正确用法

@gdtv 你们是用指令集写程序嘛？包括汇编都有性能损失哈～～

@ywgx
@lincolnhuang
@0x8C
上云了又怎样，不需要运维？
从楼主的描述中就能知道这是开发普遍的现象，开发时间都在写代码上去了，能做完需求，写出没坑的代码就不错了，架构的事情弄懂并实际操作过的开发有多少，而且开发环境的部署跟生产环境的部署能一样?
云上提供的各种服务，开发知道怎么选型并把它们用好的又有多少。
另外服务不是部署上去就完事了，网络出故障了怎么排查，怎么进行有效的监控，告警（云上的监控告警真的能满足你们的需要？）
当云上没有你需要的功能时，是不是得自己搞，这个时候上云跟不上云区别在哪里？
认为上云就不用管这些事情的，如 @FFLY 所说，认知就是偏的

配管做

运维做，你们的产品成熟度还很差

@cynial 云服务又不是只有虚拟机，网络问题发 case，监控可以找云监控服务商。所以目前运维的方向是从交付上线开始，性能调优，系统架构和运维开发，如果交付上线都是别人做，那运维真没什么事情做了。

@shadowwalker2644 #22 开发写部署脚本没问题，那就是 DevOps 了，但是真正能完美做到的公司很少吧。运维按部署文档部署出了问题来找你，其实责任也很明确，开发没写清楚部署文档，或者运维没按照部署文档操作。

说 docker 有性能损失。。。。。

我测过 docker tcp 反向代理的性能，那叫一个强。说 docker 有性能损失我是不认同的，你的服务器就不能接受那 1% 的 CPU 占用？平时都是 99% CPU 在跑？

扯性能问题的人，99.9999% 是小白，剩下的才是真的遇到了性能问题。

我不用 docker 是因为他复杂，如无必要，勿增实体。

docker 可比虚拟机轻太多了，要是有个好一点的运维开发来支持 DevOps 绝对要上啊，用不上大多是因为
1、没这么高的运维需求
2、没钱没人做运维

@buliugu Docker 比虚拟机轻，但虚拟机比 Docker 使用方便得多啊