Git:应用程序配置和不同的环境 [英] Git: application configuration and different environments

查看:160
本文介绍了Git:应用程序配置和不同的环境的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们使用 git 对我们在店铺中构建的大多数Web应用程序,尽管应用程序本身也使用各种技术(PHP,Rails等),我们通常为每个站点分配和生产服务器。通常,这些服务器具有不同的数据库凭据集以及不同的基于环境的配置设置(例如缓存)。我们的工作流程通常包括每个项目维护两个git分支:主,反映生产服务器和分期,反映分期。新功能是在分段(或分支)上开发的,并在完成和部署后合并回主机。



我的问题是关于最佳维护方式分支和环境特定的配置文件。我已经看到类似问题的答案这里此处 ,也没有真正满足。主要的两种方法似乎是a)使用.gitignore排除将配置文件保留在git的权限之外,或b)编写反映性,环境感知代码,什么数据库凭据使用基于主机名。我的问题是,它只允许一组配置文件存在于代码库(不管当前的分支),所以其他环境的配置文件丢失。 b),另一方面,似乎需要对代码库进行不必要的修改,这种方式与应用程序的功能无关。



理想情况下, d喜欢在某个分支中锁定配置文件的方法,所以每当我检出主机,我得到主配置文件,每当我结帐登录,我得到登台配置文件。另外,将分段合并到主机不应该以任何方式影响主配置文件。到目前为止,我们已经通过在git root之外包含特定于环境的配置文件的文件夹来处理这个问题,并在部署时手动将相应的文件移动到代码库中,但这当然不必要地是黑客(可能是危险的)。 >

有没有办法使用git完成这个?



感谢您的考虑!

解决方案

他们可以摆脱没有某种安装工具。 Git关于跟踪源,而不是关于部署。您还应该有一个make install类型的工具,从您的git repo到实际部署,此工具可能会执行各种各样的操作,如模板扩展或备用文件的选择。



例如,您可能会将config.staging和config.production签入git,并且当您部署到暂存时,安装工具将选择config.staging复制到config。或者你可能有一个config.template文件,它将被模板化为在部署中进行配置。


We use git for most of the web applications we build in our shop, and though the applications themselves use a variety of technologies (PHP, Rails, etc), we generally have a staging and production server for each site. Typically, these servers have different sets of database credentials as well as different environment-based configuration settings (e.g. caching). Our workflow generally involves maintaining two git branches per project: master, which reflects the production server, and staging, which reflects staging. New features are developed on staging (or a sub-branch) and are merged back to master upon completion and deployment.

My question is with respect to the best way to maintain the configuration files that are branch- and environment-specific. I've seen the answers from similar questions here and here, and neither really satisfies. The main two approaches seem to be a) using .gitignore exclusion to leave config files outside of git's purview, or b) writing reflective, environment-aware code that determines e.g. what database credentials to use based on hostname. My problem with a) is that it only allows one set of config files to exist in the codebase (irrespective of the current branch), so the other environment's config files get lost. b), on the other hand, just seems to require unnecessary modification of the codebase in a way that doesn't feel related to the application's functionality.

Ideally, I'd like a way to "lock" configuration files within a certain branch, so that whenever I checkout master, I get the master config files, and whenever I checkout staging, I get the staging config files. Additionally, merging staging into master shouldn't affect the master config files in any way. To date, we've dealt with this by having folders containing environment-specific configuration files outside of the git root and manually moving the appropriate files into codebase when deploying, but this is of course needlessly hackish (and potentially dangerous).

Is there any way to accomplish this using git?

Thanks for your consideration!

解决方案

Not sure why people think they can get away without some sort of install tool. Git is about tracking source, not about deploying. You should still have a "make install"-type tool to go from your git repo to the actual deploy, and this tool might do various things like template expansion, or selection of alternate files.

For example, you might have "config.staging" and "config.production" checked in to git, and when you deploy to staging, the install tool selects "config.staging" to copy to "config". Or you might have a single "config.template" file, which will be templated to make "config" in the deploy.

这篇关于Git:应用程序配置和不同的环境的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆