DevOps精品课程问题汇总 ＋ 个人问题总结

最近DevOps社区在进行精品课程的活动，特此对每一节课的问题及回答进行一点汇总以及个人对某些问题的理解。

DevOps前世今生

1. Q：到底是技术推动DevOps的发展还是DevOps推动技术的发展？

   A：其实是个循环，技术变更引起DevOps改革，再反向影响技术变更适应DevOps

2. Q：DevOps可以是同一个人，或同一个团队吗？ops的编程能力需要和dev的编程能力相当吗？

   A： 实际上DevOps推荐的是一个角色，开发自运维，不明确区分dev和ops。

3. Q： devops中提到了lean，那么跟agile中说的lean，岂不有重叠了，敏捷开发和devops的关系是怎样的？都说devops是agile的下一种形式，两者是取代和被取代的关系么？

   A： 敏捷是一种思想，快速反馈，DevOps是实现敏捷的一个必要手段。

4. Q： 目前的公司一般都停留在CI中，用Jenkins编译打包部署，如何过度到devops中呢？

   A： CI已经实现的情况下，需要往CD（持续部署）上走，做到传说中的有包就能部署的地步，然后实现产品对市场反馈快速回应，形成开发到产品的一个循环链

5. Q： 敏捷和瀑布模式并行的时候，如何应用devops？

   A： 敏捷可以直接用devops没问题，瀑布谈devops还有点难，可以先试着转敏捷，将长周期项目缩短，拆分功能点等手段保证项目逐步转型。

   Q： 瀑布的开发就要到那个时间点才能完成，敏捷的要依赖他，就敏捷不起来，受目前的系统架构影响，其他系统敏捷不起来

   A： 拆，敏捷依赖哪个点，就把那个点想办法拆的周期短一些，再通过优先级裁定集中火力拿下这个阻塞点。

6. Q： 如果开发同时兼顾dev和ops，那么ops岂不就下岗了？

   A： 其实现在越来越多的ops代码已经渗透到dev中了，比如服务熔断，发现等，ops应该更偏PAAS层级了，SAAS层级的ops应该转给dev一起搞了。

DevOps工具与实践

1. Q： 蓝绿部署如何解决： 蓝在部署中（包括升级db）时，绿的数据库发生变动。切换后数据不一致的问题？

   A： 数据库要保证向前兼容。 推荐做法是蓝的db升级保证兼容绿的。 在开发过程中对db的改动需要考虑蓝绿部署兼容，比如增改表，增改字段等操作，删除操作延后一个部署周期。 如果只有一台数据库实例时，还需要考虑数据迁移。

2. Q： jar包之间的配置文件管理有什么好的方法或工具
   A： Spring Cloud Config 或者Zookeeper都可以做到

3. Q： 在从本地代码库 push 到github之前，想做预编译，编译通过以后才允许push。有没有什么好的实践介绍？

   A： 回答1. 我们目前项目的做法是会用自定义的push命令来提交代码，提交之前跑JT，格式化代码和编译，过了之后才真正push到Github

   回答2.我们之前会有ci分支，代码合并到ci后Jenkins 回去做findbugs pmd，完了会给出报告，通过后，才会允许发送pr到dev，失败了就需要改代码，当然ut也是这个时候做的

4. Q： 蓝绿部署如何解决： 蓝在部署中（包括升级db）时，绿的数据库发生变动。切换后数据不一致的问题？比如说说绿中新更新的record， 这也update的event是不是要在切换到蓝时在蓝中前执行一遍？例子： User 有name字段，migration脚本是加一个sex字段。user1叫john。他在蓝升级过程中，把绿中的name换成了mike。这是切换到蓝后，他的名字还是john。更名的数据不就丢失了吗？

   A： 方案一：加时间戳，可以确定最终数据是哪个。

   方案二：杜绝这种现象，蓝的环境只允许操作特定账户，并且这些账户只在蓝中操作

讲师推荐

1. https://www.jianshu.com/nb/4573135?utm_campaign=hugo&utm_medium=reader_share&utm_content=notebook&utm_source=weixin-friends

2. https://www.jianshu.com/p/645bb1283a77?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends

其他

作为一个工作时间很短的人，我经历的项目有限，因此就某些问题问了一下首席，其中夹杂了一些个人观点，如有错误欢迎指正。

敏捷与瀑布如何并行？什么样的场景？

在诸如银行一类的地方中会有很大型的系统，尤其是后台的处理系统，这种系统是不适用于敏捷的。首先，这些系统不允许出现问题，因为一旦出现问题，很有可能就是事故，因此需要各种各样的测试来保证，这些测试就会花费很多的时间。其次，这些后台处理系统不涉及到用户的体验设计，不需要响应客户的变化。因此这些厚重的后台系统都是实行的瀑布。

但是其对应的前台可以是千变万化的，像很多银行都推出了自己的手机银行，手机银行还有网页端这些直接面对客户的地方，就需要快速响应银行的变化，根据其推出的产品来进行页面、内容的更改。因此这些偏前端的、直接面对客户的系统就是敏捷的。但是其在后台始终调用的都是后台写好万年不变的那些接口。

对于第一课的Q5，不知道项目上具体是怎么回事，不过有一个小的想法，如果事先定义好接口，接口始终不变，作为调用接口的那一方，接口后边其实是个黑盒，无论是瀑布还是敏捷都无所谓，只要调用这个接口，返回的是想要的东西就好，不知道这样是否可以解决敏捷和瀑布并行的问题。

蓝绿部署时数据库写入如何同步的问题

场景：实行蓝绿部署，其中蓝上为最新代码，假设为6月的代码。绿上为5月的代码。期间数据库发生了变动，如问题中举的例子，最新的数据库中User 有name字段，migration脚本是加一个sex字段。user1叫john。他在蓝升级过程中，把绿中的name换成了mike。这是切换到蓝后，他的名字还是john。

方案一：使用主从。即设置蓝为主，绿为从。蓝改变的时候，绿中的数据库会跟着改变。由于绿不知道蓝的存在，因此绿改变的时候，蓝的数据库不会随之改变。

为什么不能使用主从？

刚刚提到了，由于绿不知道蓝的存在（因为绿是早期版本的代码，无法向上兼容），因此绿的数据库改变时，蓝的数据库不会改变。如果绿上的更改为最新更改，蓝那边始终都不知道，这个数据还是相当于丢失了。

方案二：加时间戳。这个方案是在每一次操作后加上时间戳，这个方案是可行的，因为可以有效的判断哪一个数据是最新数据，在最终同步的时候使用最新的数据即可。

方案三：杜绝这种现象，蓝的环境只允许操作特定账户，并且这些账户只在蓝中操作。