使用 Mercurial 管理 Web 开发和部署之间差异的最简单方法?

发布于 2024-09-29 09:37:14 字数 474 浏览 6 评论 0原文

我正在使用 Mercurial 进行网站开发。我“认为”我正确使用它。

我在我的开发机器上进行开发,并定期提交。我会定期将我的提交推送到我托管的站点开发存储库。

如果一切按照我想要的方式设置为实时站点,我就会从我的开发计算机推送到托管站点实时存储库。然后我从该存储库下载到实时服务器。

但是,需要进行一些更改(将目录从 localhost 更改为 www.example.com、更改数据库连接内容等)。

我所做的就是在我的实时计算机上进行这些更改,然后将它们推送回站点实时存储库。我真的不知道为什么要这样做,但至少有一个变更集包含必要的配置更改。

我不知道如何管理这个过程。除了承诺、推动和拉动汞之外,我有点迷失了。我是一名单一开发人员,甚至还没有进行合并。

有没有某种方法可以识别特定的变更集,然后应用它,甚至希望在我从存储库拉取到实时服务器之前?

我想你可以从我的问题中看出我现在对 hg 和工作流程有点不知所措;)

I am using mercurial for website development. I "think" I'm using it correctly.

I develop on my development machine, commit fairly regularly. I will somewhat regularly push my commits to my hosted site-dev repository.

If things are set up how I want them for the live site, I push from my dev machine to the hosted site-live repository. Then I pull down from that repository onto the live server.

However, there are some changes that need to be made (changing directories from localhost to www.example.com, changing the DB connection stuff, etc.).

What I did was made these changes on my live machine, then pushed them back up to the site-live repository. I don't know why I did that, really, but at least there's a changeset sitting there with the necessary config changes.

What I don't know how to do is manage this process. I'm a little lost beyond committing, pushing and pulling with hg. I'm a single developer and haven't even done a merge yet.

Is there some way to keep that particular changeset identified, and just apply it, hopefully even BEFORE I pull from the repo down to the live server?

I think you can tell from my question that I'm in a little over my head with hg and workflow at the moment ;)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

缘字诀 2024-10-06 09:37:14

这是我的理解:

本质上你想要做的是拥有一个开发、暂存和部署环境。您使用“开发”存储库进行开发,在临时环境中进行测试,然后在满意后将这些更改拉入部署存储库。
当您从暂存到部署时,您需要更改环境/配置数据。

我的看法是你根本不应该改变配置。

您应该拥有配置文件,以便拥有

  1. 基本配置文件

    <块引用>

    基本.conf

  2. 环境特定覆盖

    <块引用>

    basic.dev.conf、basic.staging.conf 和 basic.conf。部署.conf

  3. 使用环境变量:

    <块引用>

    应通过环境定义对基本配置数据的覆盖
    特定变量:APP_ENV:开发或登台或部署

这样您应该能够根据环境覆盖配置,而无需更改配置信息。

每次将代码从开发阶段拉到部署阶段时都依赖于对配置文件进行更改并不是一个好主意。

This is my understanding:

What essentially you are trying to do is have a development, staging and deployment environment. You do your development using 'development' repository, test it on a staging environment and then once satisfied, pull those changes into deployment repository.
And when you pull from staging to deployment, you need to change your environment / configuration data.

My take is you should not be changing the configuration at all.

You should have configuration files such that you have a

  1. basic configuration file

    basic.conf

  2. Environment specific overrides

    basic.dev.conf, basic.staging.conf and basic. deployment.conf

  3. Use environment variable:

    The overrides to the basic configuration data should be defined via an environment
    specific variable : APP_ENV : dev or staging or deploy

This way you should be able to override the configuration based on the environment without changing the configuration information.

It is not a good idea to rely on making changes to config files each time you pull your code from development to staging to deployment.

探春 2024-10-06 09:37:14

我会将实时服务器置于版本控制之外。这意味着我将有一个小的“安装”脚本,它从存储库中提取更新,删除任何不必要的开发文件,并应用正确的配置文件。开发和生产配置文件都应该处于版本控制中。

I would keep the live server outside the version control. Meaning that I would have a small "install" script that pulls updates from the repository, removes any unnecessary development files, and applies the correct configuration files. Both development and production configuration files should be in version control.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文