Capistrano：共享/中文件的版本控制
当 Capistrano 部署 Rails 应用程序时，它会创建一个 shared/ 目录来存储应跨版本共享的文件，而不是每次都重新导出。在我的应用程序中，我的 shared/ 目录中有几项很少更改（因此它们属于那里而不是应用程序树中），但我仍然希望它们在以下情况下受到版本控制：他们确实改变了。
对这些文件进行版本控制但将它们与 Capistrano 从中导出的存储库分开的最佳方法是什么？
When Capistrano deploys a Rails app, it creates a shared/ directory to store files that should be shared across releases and not re-exported every time. In my application I have several things in the shared/ directory that rarely change (so they belong there rather than in the application tree), but I'd still like them to be version controlled for the times when they do change.
What is the best way to approach version controlling those files but keeping them separate from the repository Capistrano is exporting from?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
/shared 目录实际上用于存储未版本化的数据。例如，您可以存储捆绑的 gem，这样您就不必在每个版本中重新安装所有 gem。您还可以将日志存储在那里，这样它们就不会在每次部署时被覆盖。您可以将 pid 文件存储在那里，这样您就不会在部署期间丢失关键进程的进程 ID。您甚至可以将用户生成或部分处理的数据存储在那里，以便在发布期间不会将其删除。如果一个文件需要进行版本控制并且有可能发生更改，我建议将其与其他文件一起保存并放在共享目录之外。
也就是说，您始终可以编写部署脚本来预先填充共享目录中的数据，例如数据库配置文件。这些脚本将在每次部署时运行，并且可以完全自定义。例如，您的数据库配置脚本可能仅写入配置文件（如果该文件尚不存在）。
The /shared directory is really for un-versioned data. For example, you might store bundled gems so that you don't have to re-install all your gems every release. You can also store you logs there so they don't get overwritten every time you deploy. You can store pid files there so you don't loose the process ids of critical processes during a deploy. You might even store user generated or partially processed data there so that it is not removed during a release. If a file is meant to be versioned and has the chance of changing though, I would recommend keeping it with the rest of your files and out of the shared directory.
That said, you can always also write deploy scripts to pre-populate data in your shared directory, like database configuration files. These scripts will get run on each deploy and can be entirely customized. For example, your database config script might only write the config file if it doesn't already exist.
共享目录的另一个常见用途是用于配置文件。配置文件的版本控制和源代码控制是一个非常好的主意，但应该在系统配置管理工具中进行管理。在我的环境中，我使用 Capistrano 管理代码发布，并使用 Puppet 管理系统配置。这样，仍然可以对配置文件进行源代码控制，但它们与代码部署过程保持不同。反过来，代码部署过程独立于系统配置。
Another common use of the shared directory is for configuration files. Versioning and source control for configuration files is a very good idea, but should managed in a system configuration management tool. In my environment, I manage code releases with Capistrano and system configuration with Puppet. That way, there is still source control over configuration files, but they are kept distinct from the code deploy process. In turn, the code deploy process is kept independent of system configuration.