对包含 MediaWiki 和 WordPress 安装的网站开发项目进行版本控制的好方法是什么？

发布于 2024-10-16 19:55:10 字数 886 浏览 2 评论 0原文

我正在尝试找出包含 MediaWiki 和 WordPress 安装的网站的版本控制程序。我刚刚开始思考这些问题，可能问得太快、太模糊了。

假设网站根目录是

~/public_html

有各种静态 HTML 页面

~/public_html/page1.html
~/public_html/dir/page2.html
...

并且安装了 MediaWiki

~/public_html/wiki/

和 WordPress

~/public_html/blog/

以及可能的其他具有数据库后端的 Web 应用程序。

有几个问题我不清楚

如果我使用 Subversion，我的第一步是什么？由于我已经在我的 Web 服务器计算机上运行了 /public_html，我是否需要先将完整的 /public_html 下载到我的本地开发计算机，然后将其作为项目提交到我的 svn 服务器（单独）？我还有其他使用 Subversion 进行版本控制的软件项目。
如果我使用 Subversion ，当我部署时，我是否只需签出，即服务器使用的网站将是存储库的工作副本？ MediaWiki 和 WordPress 的版本是否正确？另外 .svn 目录又如何呢？这不会暴露吗？
除了 /public_html 中的文件的版本控制之外，如何以与 public_html 中的文件简化的方式备份数据库？
如果我使用 Mercurial，我可以使用 public_html 作为存储库，并且不一定需要克隆存储库？

原文

I am trying to figure out version control procedures for a website that includes MediaWiki and WordPress installations. I just started thinking about these and am probably asking too quickly and vague questions.

Say the website root is

~/public_html

There are various static HTML pages

~/public_html/page1.html
~/public_html/dir/page2.html
...

And there are installations of MediaWiki

~/public_html/wiki/

and WordPress

~/public_html/blog/

and possible other webapp that have database backend.

there are a few questions not clear to me

If I use Subversion, what's my first step? As I already have a /public_html running on my web server machine, do I need to download the complete /public_html to my local development computer first and then commit it to my svn server (separate) as a project? I have other software projects that are version controlled using subversion.
If I use Subversion , when I deploy, do I just check out, i.e. the website that's used by the server will be a working copy of the repository? Will the MediaWiki and WordPress be properly versioned? Also what about the .svn directories? Won't that be exposed?
besides version control the files in /public_html how do I backup databases in a way that's streamlined with the files in public_html?
If I use Mercurial instead, I can use public_html as the repository and don't necessarily need to clone out a repository?

分享到QQ

分享到微博

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

发布评论

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

心如荒岛 2024-10-23 19:55:11

我使用源代码控制、脚本和部署程序来管理一些 Web 应用程序项目，例如 WordPress、phpbb 和自定义 Web 应用程序。多年来，我改进了这些框架，现在我有了一个似乎对我来说很有效的框架，因此它可能适合面临类似挑战的其他人。

以下是有关总体策略的一些一般要点：

我在生产服务器上从来没有 SCM 和源文件。我认为没有任何理由将其放在那里，并且通常我不希望存储库在服务器损坏的情况下暴露。生产服务器上的应用程序仅具有干净的最新稳定版本。没有项目文件、文档、单元测试等。任何不需要的东西都不存在。我发现从安全性和应用程序稳定性的角度来看这都非常重要。
并不是要把这变成 SCM 争论，但我发现就我的目的而言，mercurial（和 git）在任何方面都比 SVN 更好。您不需要任何“服务器”，并且存储库更易于维护。
我为每个项目保留单独的存储库。 Mercurial 存储库便宜且轻量。将每个项目保存在自己的存储库中提供了极大的灵活性。所以没有一个大型的“public_html”存储库。
我在开发机器上使用本地 Mercurial 存储库。一切都按原样备份（使用任何备份策略 - 附加机器、外部驱动器、云备份）。共享代码就像提供项目目录一样简单。有时我将存储库保存在 dropbox 上，这样我就可以从任何地方访问它们。
部署由部署脚本自动完成（稍后会详细介绍）。它导出所需的修订版本，对其进行编辑并将其上传到服务器。
数据库转储不存储在 SCM 中。对于任何实际项目来说都是不切实际的。我在 SCM 中存储数据库结构的转储，并在结构发生变化时更新它（为此我使用 mysql dump 或 phpmyadmin）。有时，将骨架数据的转储与结构（具有默认值、查找值等的表）一起存储在 SCM 中是有意义的。
数据库备份是通过在生产服务器上运行的自动脚本（automysqlbackup 效果很好）完成的。转储数据库、存档并轮换文件（每月、每周、每天）。还有一个脚本每天将备份转储文件下载到异地位置。这对于数据量相对较小的项目非常有效。显然，对于大型数据库，这需要改变。
我通常为开发和生产保留单独的数据库实例。尽可能少地修改生产数据库。当我需要测试/调试某些内容时，我会使用实时数据的副本更新我的开发数据库。
有时，我在生产服务器上有应用程序的第二个副本，用于登台/单元测试，但这里无法描述太多。
所有部署均通过 SSH 进行隧道传输，这是服务器上允许的唯一连接（当然，http/s 除外）。我将 SSH 密钥文件保存在开发计算机上。或者，您可以使用 VPN 作为隧道。
我假设使用 linux/BSD 生产服务器。所有这一切在 Windows 服务器上都将完全不同（并且通常更困难）。我在Windows、Mac和Linux开发机器上使用了这些程序，所有工具都可用。

因此，为了回答你的一些问题，我会反过来做。从开发计算机上的工作环境开始（配有 Web 服务器和数据库）。让您的应用程序在那里运行并进行测试。根据需要将更改提交到本地存储库。应用程序准备好部署后，运行部署脚本以自动更新生产站点。

我的部署脚本执行如下操作：

将所需的修订版导出到本地临时部署目录（mercurial、git、SVN 都具有从存储库创建工作目录的导出命令）
修改部署的目录以使其适合实时部署。这包括修改配置文件、更改数据库名称、路径、日志设置、调试级别等。使用脚本、sed、awk、grep 或任何所需的命令行工具。
如果需要，从 SCM 修订数据、部署日期等生成 version.txt（或任何名称）文件。该文件将上传到服务器。
将我的 SSH 密钥添加到 SSH 代理（以避免每次都使用密码）。
使用 rsync（通过 SSH 隧道）将所有内容同步到服务器。服务器需要正确配置为 rsync 目标。使用 rsync 排除/包含过滤器排除不需要的所有内容（通常是 .*，除了 .htaccess）。
如果需要，可以使用 SSH 远程执行功能在服务器上运行命令来执行设置特殊权限（例如，Wordpress 上传目录的写入权限）等任务。
给我一个很好的“部署成功”消息:)

就是这样，一旦脚本就位，部署就变得很有趣。运行脚本，进入实时服务器以查看一切正常，完成。

希望这有帮助。

I am using source control, scripts and deployment procedures to manage few web application projects like wordpress, phpbb and custom web applications. Over the years, I refined these and now I have a nice framework that seems to work well for me, so it may suit others facing similar chalenges.

Here are some general points about the overall strategy:

I never have SCM and source files on the production server. I don't see any reason to put it there and usually I don't want the repositories exposed in case of server breach. The applications on the production server only have the clean latest stable revision. No project files, docs, unit testing, etc. Anything that isn't needed isn't there. I find this very important both from security and application stability points of view.
Not to turn this into SCM debate but I found that for my purposes, mercurial (and git) are better than SVN in any aspect. You don't need any "server" and the repositories are easier to maintain.
I keep separate repository per project. Mercurial repositories are cheap and lightweight. Keeping every project in its own repository gives great flexibility. So no one big repository for "public_html".
I work with local mercurial repositories on the development machine. Everything is backed up as is (using whatever backup strategy - additional machines, external drives, cloud backup). Sharing code is as easy as just giving the project's directory. Sometimes I keep repositories on dropbox, so I can access them from anywhere.
Deployment is done automatically by a deploy script(s) (more details later). Which exports the desired revision, edits it and uploads it to the server.
Databases dumps are not stored in the SCM. It is not practical for any real project. I store a dump of the database structure in the SCM and update it any time the structure changes (I use mysql dump or phpmyadmin for this). Sometimes it makes sense to store a dump of a skeleton data in the SCM along with the structure (tables with defaults, lookup values etc).
Database backup is done by automatic script (automysqlbackup works well) that runs on the production server. Dumps the database, archives it and rotates the files (monthly, weekly, daily). There is also a script that downloads the backup dump files to an off site location daily. This works well for projects with relatively small-medium data sizes. Obviously, this will need to change for large databases.
I usually keep separate database instances for development and productions. Messing around with the production database as little as possible. When I need to test/debug something, I update my development database with a copy of the live data.
Sometimes I have a second copy of my application on the production server for staging/unit testing but that's too much to describe here.
All deployment is tunneled over SSH, which is the only connection allowed on the server (except for http/s, of course). I keep SSH key file on the development machine. Alternatively, you can use VPN as the tunnel.
I am assuming linux/BSD production servers. All this will be totally different (and usually harder) on Windows server. I used these procedures on Windows, Mac and Linux development machines, all the tools are available on all.

So, to answer some of your questions, I'd do it the other way around. Start with a working environment on your development machine (complete with web server and database). Have your applications work and tested there. Commit changes to the local repository as needed. Once the application is ready for deployment, run the deploy script to automatically update the production site.

My deploy script do something like this:

Export the desired revision to a local temp deploy directory (mercurial, git, SVN all have export commands that create a working directory from your repository)
Modify the deployed directory to make it suitable for live deployment. This includes modifying config files, changing database names, paths, log settings, debug levels etc. Using scripts, sed, awk, grep or whatever command line tools needed.
If needed, generate version.txt (or whatever name) file from the SCM revision data, deploy date, etc. This will be uploaded to the server.
Add my SSH key to the SSH agent (to avoid using passwords each time).
Use rsync, tunneled over SSH to sync everything to the server. The server will need to be properly configured as the rsync destination. Use rsync exclude/include filters to exclude everything not needed (often it is .* except .htaccess).
If needed, use SSH remote execution capabilities to run commands on the server to do tasks like setting special permissions (for example, write permissions on Wordpress upload directories).
Give me a nice "deployment successful" message :)

That's it, once the script is in place deployment becomes fun. Run a script, go the the live server to see everything works, done.

Hope this helps.

回复收藏 0 原文

~没有更多了~