如何使用 subversion 管理生产/测试/开发配置信息？
我正在开发一个组合的 Web/客户端应用程序，该应用程序具有用于生产、测试和开发的分支。 我正在使用 svn post commit hook 将更新部署到生产和测试服务器。 客户端应用程序需要根据生产、测试或开发指向不同的 URL。 我如何使用 subversion 来管理这个？ 我想到的选项有：
选项 1
保留一个包含特定于分支的详细信息的文件，该文件永远不会在分支之间合并。
从构建管理的角度来看，此选项更容易，但很容易出错，因为我必须记住每次执行合并时忽略该更改。
选项 2
无论哪个分支，都可以创建客户端的生产、测试和开发版本，并依靠 svn 挂钩来获取正确的二进制文件。
你如何处理这个问题？ 还有更好的想法吗？
I'm working on a combined web/client app that has branches for production, test, and development. I'm using svn post commit hooks to deploy updates to the production and test servers. The client app needs to point to different urls depending on production, test, or development. How can I manage this using subversion? Options I've thought of are:
Option 1
Keep a file with branch-specific details that is never merged between branches.
This option is easier from a build management perspective but is prone to error since I have to remember to ignore that change every time a merge is performed.
Option 2
Create production, test and development builds of the client no matter which branch, and rely on svn hooks to pull down the correct binaries.
How do you handle this? Any better ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们的应用程序为每个部署的环境保留一个单独的目录，其中包含配置文件。 当构建服务器运行针对特定环境进行部署的任务时，它知道从哪个目录提取配置文件。 指向正确目录的指针是构建服务器（在我们的例子中为 Pulse）的构建定义的一部分。 为该 Pulse 任务构建代码的分支也是任务规范的一部分。 这使得部署服务器决策独立于分支，因此当我们发布新版本时，服务器和数据库可以重新调整用途。
配置文件不与应用程序的其余部分（主干、分支等的同级）进行分支。 它们在 svn 树中有自己的位置，并作为 被拉入每个分支。 Subversion 外部定义。
我们这样做是因为每个分支可能部署了许多服务器（开发、测试、构建、自动化等）。
Our application keeps a separate directory with configuration files for each deployed environment. When the build server runs the task to deploy for a specific environment it knows which directory to pull the config files from. The pointer to the correct directory is part of the build definition for the build server (in our case Pulse). Which branch the code is built from for that Pulse task is also part of the task specification. This makes the deploy server decision independent from the branch so as we release new versions servers and databases can be repurposed.
The config files are not branched with the rest of the application (a sibling of trunk, branches, etc...). They have their own spot in the svn tree and are pulled in the each branch as a Subversion external definition.
We do it this way because each branch may have many servers deployed from it (dev, test, build, automation, etc).
我的偏好是不将项目特定的配置文件签入源代码管理，而是将环境变量的内容和其他配置方面保留在公共文件夹中（在源代码管理中）。 然后，根据给定项目、解决方案、环境在给定时间可能需要的内容，将配置文件作为本地构建、构建自动化或部署脚本的一部分生成。 这可以通过简单的文本文件、xml 模板或更复杂的东西（如 Spark 视图引擎）来完成，具体取决于您的需要。 如果模板比您需要的更复杂（通常是这样），您也可以按照惯例执行此操作。 这样，无论您在何处部署代码，都可以定义特定于环境的配置。
按照约定的一个示例是在主配置文件（Web 配置、应用程序配置等）中定义自定义配置部分。 然后，您可以存储connection-strings-development.config、connection-strings-integration.config、connection-strings-testing.config、connection-strings-pre-production.config 和connection-strings-product。在您的主要源（或公共文件夹）中配置。 然后，构建过程将删除适当的连接字符串配置文件，将其重命名为简单的connection-strings.config。
通过模板生成，您还将拥有具有相同环境特定配置文件的自定义配置部分，但您可以简单地使用适当的配置文件名直接重写基本配置文件的一部分，而不是在部署时重命名。
不过，按环境将配置文件分成块可以为您提供很大的灵活性，特别是当您开始管理许多使用相同或相似配置风格的站点时。 无论如何，您的配置应该由自动化环境的某些方面决定！
My preference is to not check in project specific configuration files to the source control but instead keep the contents of environment variables and other configuration aspects in a common folder (in source control). The config files are then generated as part of the local build, build automation, or deployment scripts depending on what a given project, solution, environment might need at a given time. This can be done with simple text files, xml templates, or something more complex like the spark view engine depending on your needs. You can also do this by convention if templating is more complex than you need (and it normally is). This way, no matter where you are deploying code too you can define an environment specific configuration.
An example of by convention is to define custom config sections in your primary config files (web config, app config, etc.). You can then store a connection-strings-development.config, a connection-strings-integration.config, a connection-strings-testing.config, a connection-strings-pre-production.config, and a connection-strings-production.config in your primary source (or common folder). The build process would then drop the appropriate connections string config file renaming it to simply connection-strings.config.
Generating by template you would also have custom config sections with the same environment specific config files but instead of renaming on deployment you can simply rewrite a section of the base config file directly with the appropriate config file name.
Keeping your config files chunked up by environment though provides you with a great deal of flexibility especially once you start managing many sites that use the same or similar style of configuration. No matter what though, your configuration should be dictated by some aspect of your automated environment!