我是运维同学，而且现在工作内容部分也是 配合开发人员部署线上环境。公司也有用 Jenkins 所以来说说：
首先，请不要讨论我司当前部署过程的低效率性与低技术含量等[已经在修改了，目标是完全自动化流程。楼上有人讲到“配置中心”等等这种]。

题主公司开发环境我不清楚，但我司的开发人员是接触不到 生产服务器的环境。项目都是在自己本地测试通过，然后传到 SVN 。运维通过 Jenkins 编译出包，删除包内的配置文件，生产环境项目做备份，删除生产环境非配置文件[config 文件夹]，部署新版到生产环境，通知开发人员与测试人员。
1.若生产环境的配置文件稳定不变，那么好，我把其余的文件更新上去便可。
2.生成环境的配置文件需修改，那么需要与开发沟通，看在生产环境上如何配置修改。

上面是最基础的两种情况，还有遇到的一种是：一些生产环境的旧配置文件虽然不需要修改，但它的存在会影响到服务，你一定要删除掉。

作为运维，大部分情况下你不清楚项目中各类配置文件的作用。而作为开发，你虽然清楚配置文件各种参数的意义，但你不清楚生产环境是如何的。所以这点决定了，传统的项目部署工作是需要开发人员与运维一起沟通进行的，一起沟通进行的，一起沟通进行的。若都各顾着各，是做不好的。

若要各自独立进行，要么这种类型： @holyzhou 提到的“开发提供详细的文档”[感觉这种显然没有面对面沟通效率高]，运维去啃；要么技术上做到彻底消除这层问题。

开发人员若不能接触或者不清楚生产环境的情况下，让他们出可以保障直接运行在生产环境的项目包，显然是有点扯淡的；若生产环境或者说生产环境的完全模拟是对开发人员完全开放的，那你作为开发人员就要保障做到项目的正确配置。

最后：一定要多沟通，从根本上解决问题。明确自己的责任，做好自己的工作内容。

本来是下午要发上来的，但不知道为什么网站那段时间不太稳定，访问超时+502 错误。。。