我习惯用简单的命令来定义gemfile，例如gem 'devise'。我现在要通过AWS上的一个dockerized容器以及一个基于推送到Git上的master分支来构建新容器的管道，将我的App投入生产。这意味着每次我推送新版本时，AWS都会从头开始重建整个应用程序，同时还会安装所有最新版本的gem。
我担心新版本的宝石会发生什么。当然，这可能意味着如果所包含的gem更改了其行为或方法，我的代码可能会停止工作。
此案例的最佳做法是什么？我应该开始明确定义想要的宝石版本吗？如果是这样，我如何确保我从提供的修复程序中获利？
我正在考虑这样定义所有宝石：
gem 'devise', '~> 4.6.0'
# Or
gem 'devise', '~> 4.6'
最灵活但又能“确保”从长远来看不会出现任何问题的是什么？
答案 0 :(得分：2)
通常应使用Gemfile.lock防止意外的版本更改，该版本包含上次安装/升级的确切版本，并与gemfile一起提交，可用于确保每次生成的版本都完全相同。首先，我将研究为什么您的构建管道不使用它。
即使您具有配置项（CI）和良好的测试覆盖范围，也可以防止生产中断，最好还是确保某些故障不是由于您的更改而是因为宝石更新而导致的。因此，gem更新（即使是次要版本和补丁版本）也应单独提交。
对于gemfile本身中的版本-您应该根据特定gem的版本策略指定版本依赖性（即使依赖于锁定文件）。大多数gem使用semantic versioning，因此gem不应在一个主要版本（~>4.6选项）内破坏任何内容，更新也不需要对应用程序进行重大更改（但是无论如何，可能会有不推荐使用的内容充斥您的日志或一些回归，因此在任何情况下都最好在生产前对版本进行测试。
要及时了解依赖项的新版本-定期运行bundle outdated来查看其中有哪些gem更新。