Git、Beanstalk、WordPress 终极部署方法

发布于 2024-12-01 02:27:15 字数 189 浏览 2 评论 0原文

我使用 Git 和 Beanstalk 在本地开发 WordPress,然后通过 Beanstalk 的部署过程部署到生产服务器。 但是如何将生产服务器上所做的更改同步回我的本地开发/git 存储库?只要有人安装插件,服务器上的更改就会发生。有没有办法将这些更改拉回本地?

我感谢任何有助于初学者理解的帮助。谢谢!

I'm using Git and Beanstalk to develop WordPress locally and then deploy to the production server with Beanstalk's deployment process. But how do I sync changes that are made on the production server back to my local development / git repo? Changes on the server will happen anytime someone installs a plugin. Is there a way to pull those changes back into local?

I appreciate any help with a Beginner's understanding in mind. Thanks!

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

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

发布评论

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

评论(3

ヅ她的身影、若隐若现 2024-12-08 02:27:15

我运行一个 CMS,正如我在评论中所说,我在 manojlds 的帮助下设置了工作流程。我想扩展我们的实施,希望能帮助您处理用户创建的内容。

我将 gitolite 设置为我们的远程存储库。它很摇滚。

我们的分支模型是这样工作的,以 WordPress 作为上下文:

master - # this is the _vanilla_ install of wordpress with no modifications
prod - # the branch that the production server pushes/pulls to
dev - # dev environment pushes/pulls to, in our case a server
alpha - # really early development, ideas, etc - my personal branch that i work on mostly
features (opt) - # as needed, I'll make feature branches then merge them into the other branches.

我们的产品每天处理大约 40-45 个不同的静态文件,有一个 cron 每天自动添加/提交用户更改的文件和数据。这将获取所有基于用户的更改,并且(在您的情况下)将获取插件安装。这很棒,因为您有他们的安装历史记录。

对代码库的实际更改通常在 alpha 中进行探索,然后合并到开发中。我们创建了一些钩子,当我们推送到开发分支时,开发服务器会自动拉入新的提交。然后它们就会同步。

在开发环境中进行测试后,我将本地生产分支与远程同步,如上所述,每天都会获取用户内容提交。然后我将合并cherry-pick提交到产品中,然后推送到gitolite上的产品。之后,产品服务器拉动,每个人都很高兴。

这听起来工作量很大,但实际上非常有效,尤其是在编写一些钩子脚本之后。我仍在调整我们的部署(例如,我几乎可以完全摆脱 alpha 分支并在本地处理 dev/feature),但是实际上,我们获得了生产服务器的每日快照,并且能够随时同步所有分支,这给我们带来了巨大的好处。

另外,关于您的 master 分支 - 将其保留为 WordPress 的普通安装非常棒,因为您实际上可以轻松测试新版本升级。您可以只检查 master 然后运行更新,并慢慢集成自定义。

I run a CMS, and as I said in the comment, I got my workflow setup with the help of manojlds. I wanted to expand upon our implementation in hopes of helping you out with user created content.

I setup gitolite as our remote repository. It rocks.

Our branching model works like so, with WordPress as the context:

master - # this is the _vanilla_ install of wordpress with no modifications
prod - # the branch that the production server pushes/pulls to
dev - # dev environment pushes/pulls to, in our case a server
alpha - # really early development, ideas, etc - my personal branch that i work on mostly
features (opt) - # as needed, I'll make feature branches then merge them into the other branches.

Our prod, which handles about 40-45 different static files per day, has a cron that automatically adds/commits user-changed files and data on a daily basis. That picks up all of the user-based changes, and would (in your case) pick up plugin installs. This is great because you have history on their installs.

Actual changes to the codebase are usually explored in alpha, then merged up to dev. We've created some hooks where when we push to the dev branch, the dev server automatically pulls the new commit in. Then they're synced.

After it has been tested in the development environment, I sync my local production branch with the remote, which as stated, gets a user-content commit every day. Then I'll merge or cherry-pick the commit into product, then push to prod on gitolite. After that, the prod server pulls and everyone is happy.

This sounds like a lot of work, but it's actually been very effective, especially after some hook scripting. I'm still in the process of tweaking our deployment (for example, I can almost completely get rid of the alpha branch and work off of dev/feature locally), but we get an awesome bonus in actually having daily snapshots of the production server, and the ability to sync all of the branches at any time.

Also, regarding your master branch - leaving this as the vanilla install of WordPress is awesome, because you can actually test new version upgrades easily. You could just checkout master then run the update, and slowly integrate customizations.

小苏打饼 2024-12-08 02:27:15

我认为,理想情况下不应在生产中进行更改。难道你不能考虑一种安装插件的方法,将插件添加到 git 存储库并将其推送到 prod 吗?我知道您可能正在谈论从 WordPress UI 安装插件,并将其添加到 PROD,但我认为您应该获取插件内容,添加到您的存储库并推送到 PROD。

如果这根本不可能,您必须确保在 PROD 中安装新插件时提交插件内容,然后您可以 git pull 同步内容。

Changes should ideally not be done in production in my opinion. Can't you look at a way for installing plugins whereby you add the plugin to the git repo and push it to prod? I understand that you are probably talking about installing the plugin from WordPress UI which adds it to PROD, but I feel you should get the plugin content, add to your repo and push to PROD.

If that is not possible at all, you have to make sure that the plugin content is committed when a new plugin is installed in PROD and then you can git pull the content to sync.

暖风昔人 2024-12-08 02:27:15

我认为简短的答案是这个过程被 wordpress 破坏了。
我还没有找到一个解决方案,让通过 ftp 访问的 wordpress 可以将其更改的文件添加到存储库中并成为新版本。

让我收回这句话。我的意思是没有用户干预。如果您将 ftp 映射为驱动器和/或将您的生产站点映射回您的主干中的计算机,然后提交更改,您可以将 WordPress 生产服务器上发生的事情返回到您的存储库中。

除了删除 WordPress 中所有允许用户执行编码人员认为不好的做法的好功能之外,应该有一个解决方案。我正在使用 beanstalk,如果除了部署到生产服务器之外,我还可以告诉它自动将来自生产服务器的更改添加回存储库并通知我更改,我会很高兴。然后我可以去比较正在发生的事情以及是否有问题从以前的版本重新部署。

目前情况是有限的,需要做更多的工作。我想我可以尝试构建自己的自动拉取和签入机制,但这听起来很累。如果有人知道更好的方法(除了使用 SSH 运行服务器之外),我很想听听解决方案。

I think that the short answer is that this process is broken with wordpress.
I haven't yet found a solution where wordpress, accessed through ftp, can have its changed files added to a repo and become the new version.

Let me take that back for a minute. I mean with out user intervention. If you map your ftp as a drive and/or snyc your production site back to you machine in your trunk and then commit the changes, you can get the things happening on you wordpress production server back into your repository.

Short of removing all of the nice features in wordpress that allow users to do what coders consider bad practices, there should be a solution for this. I'm using beanstalk, and I would love it if, in addition to deploying to a production server, I could tell it to automatically add changes from the production server back the repo and notify me of changes. Then I could go and diff whatever is going on and if its a problem redeploy from a previous version.

As is, the situation is limiting and requires more work. I suppose I could try and build my own automated pull and checkin mechanism but that sounds tiring. If anyone knows a better way (besides running servers with SSH) I'd be interested to hear the solution.

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