适用于实时 Sitecore 网站的 Git 源代码控制策略
首先，我对这个问题的庞大规模表示歉意，因为我确信我所提议的内容在实施方面是一个“大问题”，并且本身可能是三个或四个单独的问题。如果我不是迫切需要帮助，我不会问。
我接到了一项艰巨的任务，即修改公司在线工作的风险管理程序。
由于我们不进行备份，也不保护我们的数据，我决定，就像任何参与专业编程的人应该已经做的那样，我们将通过源代码控制来保护我们的工作。我目前使用 Git 在本地进行此操作，但其他人不使用源代码控制，最终我们失去了源代码控制提供的很多好处。我宁愿我们有一个系统，每个人都使用 Git，并强制执行这样的规则：如果它不在源代码管理中，它就不会保留。显然，我们需要一个备份计划，但作为一名开发人员，我认为要做的第一件事是在整理备份解决方案之前先理清编码方面的问题 - 显然，对此的任何建议也非常受欢迎。
我们运行一个带有 SQL Server 2005 后端的 ASP.NET 网站，运行 Sitecore 作为我们选择的 CMS。在理想的情况下，我希望将此 CMS 站点的所有变化部分置于源代码控制之下，包括数据库。
目前，我知道这不是最好的想法，我为 Sitecore 中内置的所有子布局运行一种解决方案。这是在源代码控制下，感谢 Git，我能够轻松添加分支、推送新功能并修复错误（使用 Git-flow 作为我的工作流程解决方案）。不过，我对 Git 还很陌生，所以除了提交、忽略某些文件等之外，我还没有管理过任何太复杂的事情。
除此之外，我还想使用源代码控制来获取源代码控制下的数据库内容。据我了解，您可以将 Sitecore 内容项序列化为文件系统中的一棵巨大的树（如果我没记错的话，保存为 .item 文件？）。如果这是理想的解决方案，我也想将它们添加到源代码管理中，尽管我不知道它们将保存在文件系统上的确切位置。我的文件系统现在是这样的：
- Data (Logs, indexes, etc - is this needed to be in source control?)
- Source (Helper files, although occasionally modified)
- Website (Containing all the files I edit, and other essential Sitecore stuff)
如前所述，我当前的存储库仅位于我的系统上，它由一个解决方案文件夹组成，其中包含一堆 .ascx、.ascx.cs、.ascx.cs.designer 和奇怪的文件.aspx 文件或两个。这往往会让我上传时的生活变得更轻松，因为就像“
我想要输入什么”一样，这是所有开发人员管理此内容的理想方式。尽管使用 DVCS，我还是希望将实时服务器视为主存储库，并让所有其他开发人员相互推送和拉取。我们将使用 git-flow 工作流解决方案，因为它符合我们的开发方式很好。显然，我担心的是正确设置这一点，而不会破坏目前在没有备份的服务器上非常昂贵、高流量的站点。
关于服务器上有多少数据要保留在存储库中的提示和建议、关于如何处理 Sitecore 中的序列化数据以及可能如何使用源代码管理本身作为备份到单独存储库的方式的指导将受到欢迎。这是我第一次必须为实时网站构建源代码控制系统/工作流程，因此任何关于对我来说最好的事情的指导和建议将不胜感激。
编辑：我将对此给予奖励，以尝试获得更多关于人们如何使用 Git 处理 Sitecore 的指南。
为了澄清自己，我并不是在寻找一种方法来备份我的工作，而是一种让许多开发人员可以处理它并确保网站上的代码与中央存储库保持同步的方法。例如，我之前提到过我将使用 git-flow 来管理我的工作流程。原始存储库将存在于共享服务器上（最终可能会成为测试环境），并且所有开发人员都将拥有该存储库的克隆来进行工作和推送。从这里，我希望能够将更改从共享驱动器上的原始存储库推送到实时服务器，如果发现错误则可以再次推送回来。我还想在我的存储库中包含序列化内容项。
Firstly, I apologise for the sheer size of this question as I'm sure what I am proposing is a "big deal" in terms of implementing and probably could be three or four separate questions in itself. I wouldn't ask if I weren't in desperate need of help.
I have been given the monumental task of revising my company's risk management procedures in regards to our online work.
As we take no backups, nor protect our data I have decided that, like anyone involved in professional programming should already be doing, we were going to protect our work through source control. I currently do this on a local basis with Git, but others use no source control and ultimately we lose a lot of the benefits that source control offers. I'd rather us have a system where everyone uses Git and have it enforce the rule that if it's not in source control, it doesn't stay. Obviously, we're going to need a backup plan, but as a developer I suppose the first thing to do is to sort out the coding aspect of things before getting a backup solution sorted - obviously, any advice on that too is more than welcome.
We run a ASP.NET website with a SQL Server 2005 backend, running Sitecore as our CMS of choice. In an ideal world I would like to have all the changing parts of this CMS site under source control, including the database.
At the moment, and I know this isn't the greatest idea, I run one solution for ALL sublayouts built in Sitecore. This is under source control and thanks to Git I've been able to add branches and push new features and fix bugs easily (using Git-flow as my workflow solution). I'm still quite new to Git though, so I've not managed anything too complex outside of committing, ignoring certain files, etc.
On top of this, I would also like to use source control to get the database contents under source control. As I understand it, you can serialise Sitecore content items as a huge tree within the file system (saved as .item files if I remember correctly?). If this is the ideal solution I would also like to add these to source control, although I don't know exactly where they would be saved on the file system. My file system right now is like this:
- Data (Logs, indexes, etc - is this needed to be in source control?)
- Source (Helper files, although occasionally modified)
- Website (Containing all the files I edit, and other essential Sitecore stuff)
As mentioned already my current repository is only on my system, and it consists of a single solution folder with a bunch of .ascx, .ascx.cs, .ascx.cs.designer and the odd .aspx file or two. This tends to make my life easier when uploading as, like with the
What I would like input on is an ideal way of managing this for all developers. Despite using a DVCS I would prefer to have the live server viewed as the main repository and for all the other developers to push and pull from it, and each other. We'll be using the git-flow workflow solution as it conforms to our way of development nicely. What I'm worried about, obviously, is setting this up correctly without destroying what's currently a very expensive, high-traffic site on a server with no backup.
Tips and advice on how much of the data on the server to stick in the repository, guidance on how to handle the serialised data in Sitecore and potentially how to use the source control itself as a way of backing up to a separate repository would be welcomed. This is the first time I've had to build a source control system/workflow for a live website, so any guidance and advice on what would be the best thing for me to do would be much appreciated.
EDIT: I am going to put a bounty on this to try and get more guides on how people handle Sitecore with Git.
To clarify myself, I am NOT looking for a way to back up my work, rather a way so that a number of developers can work on it and ensure that the code on the website is up to date with a central repository. For example, I have referenced before that I will be using git-flow to manage my workflow. The origin repo will exist on a shared server (which in time will likely be a test environment), and all developers will have clones of that to work on and to push to. From here, I want to be able to push changes from the origin repo on the shared drive to the live server and back again if errors are found. I would also like to include serialised content items in my repo.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
查看 HedgeHog 的 Team Development Soultions（最新版本为 3.0）。与 Visual Studio、Sitecore Rocks、Team City（或其他构建服务器）一起使用时，它可以满足您的许多需求。请访问 http://hhogdev.com/ 了解更多详细信息。
Check out HedgeHog's Team Development Soultions (3.0 is latest version).It meets many of you needs when used with Visual Studio, Sitecore Rocks, Team City (or other build server). Visit http://hhogdev.com/ for more details.
修改后的问题后修改后的答案：
好的，当我们从您那里获得更多背景信息时，让我扩展我最初的想法。既然你说你只有一次 Sitecore 许可证并且不能有单独的测试服务器等，我们总是可以稍微修改一下并仍然达到相同的效果。
如果您在运行实时 Sitecore 的同一服务器上有多个存储库怎么办？如果您可以将 Sitecore 设置为在同一文件系统上使用不同的根/存储库，例如将 url 更改为 http ://yoursite.com/blahblah/test 在测试模式下运行 Sitecore。当然，这取决于您拥有哪种许可证，即它是否与特定机器绑定。无论如何，通过这种方式，您可以在另一个分支（例如测试存储库中的开发分支）上测试您的站点，然后将内容合并到 master 并让它上线。
因此，您可以在服务器上拥有一个裸存储库，每个人都可以从中推送和拉取。您可以在同一台服务器上有两个额外的非裸存储库，一个检出 master 分支，另一个检出开发分支。如果您想在 Sitecore 站点的测试版本上测试新功能，通过 ssh 登录，您可以轻松地在测试存储库中运行“git pull”。当您对更改感到满意时，合并到 master 并推送到您的裸存储库上的 master 并以相同的方式更新实时存储库。
我认为您需要尝试找到一种方法来拥有网站的两个版本，以便您可以在更改上线之前对其进行测试。
原始帖子：
我强烈建议您将实时服务器和您当前正在处理的内容分开，即另一个存储库，您也可以在其中推送您的工作（并从中提取），该存储库充当集成存储库。通过这种方式，您可以在将代码推送到实时服务器之前在本地（您的组织本地）集成代码并对其进行测试，因此没有人会意外地将代码/数据库/任何内容直接推送到实时服务器。
我还建议您对中央存储库的数据进行备份，换句话说，git应该用作版本控制系统，而不是备份系统。即使 git 也可能会失败并导致存储库损坏，然后如果你没有任何备份，你就会被熏死。
另外，如果可能的话，尝试将实际站点内容与处理数据的逻辑分开，即尝试保持良好的模型/视图概念。这样您就可以轻松地设置一个测试环境，其中的测试数据库独立于代码，并且无需提交数据库。当然，除非你真的想提交它们:)
Revised answer after revised question:
Ok, let me expand on my original idea now when we have more background information from you. Since you say that you only have once license for Sitecore and can't have a separate test server etc, we can always modify this slightly and still achieve the same effect.
What if you had several repositories on the same server running the live Sitecore? If it's possible for you to setup Sitecore to use different roots/repositories on the same file system, e.g. you change the url to http://yoursite.com/blahblah/test to run Sitecore in test mode. This depends on what kind of license you have of course, i.e. if it's tied to a specific machine. Anyway, this way you could test your site on another branch (e.g. a develop branch in a test repository) before you merge the stuff into master and let it go live.
So you could have a bare repository on the server, where everyone push and pull from. And you could have two additional non bare repositories on the same server, one with the master branch checked out and the other with the develop branch checked out. By logging in via ssh you can easily run "git pull" in the test repository if you want to test new functionality on the test version of your Sitecore site. When you are happy with the changes, merge into master and push to master on your bare repo and update the live repo in the same way.
I think you need to try and find a way to have two versions of your site, so you can test the changes before they go live.
Original post:
I strongly suggest that you have a separation between the live server and what you are currently working on, i.e. another repository where you push your work too (and pull from) which works as an integration repository. This way you can integrate code and test it locally (local to your organization) before you push it to the live server, so no one accidentally pushes code/databases/whatever directly to the live server.
I'd also recommend that you take backups of the data for the central repository, in other words, git should be used as a version control system, not as a backup system. Even git might fail and cause corrupted repositories, and then you are smoked if you don't have any backups anyway.
Also, if its possible, try to separate actual site content from the logic working on the data, i.e. try to keep a good model/view concept. This way you can easily setup a test environment with test databases that is independent of the code, and there is no need to commit databases. Unless you really want to commit them of course :)
当我退一步尝试看看你在做什么时，我发现这是在管理失去业务连续性的风险。例如，如果您的站点出现故障，您最好能够使用备份来完全自动恢复站点。
数据存储并不昂贵。真的，事实并非如此。即使您拥有庞大的数据集。因此，要求所有开发人员使用 git 是一个好主意。许多组织设置了一个 git 服务器，您只需推/拉到该服务器即可。如果您的解决方案具有良好且完整的测试，您将很快知道代码合并是否破坏了软件。如果没有，您可能应该使用一个中央 git 服务器供开发人员进行推送/拉取，然后使用一个单独的发布集成服务器，该服务器使用“git fetch”来合并和拉取。测试来自中央服务器的更改。
您已经概述了解决方案的各种组件，例如备份代码、数据、数据库、CMS 条目等。然而，您应该问的总体问题是您是否已经收集了足够的信息以便能够仅从备份中完全激活您的网站。如果你做不到这一点，那说明你做得还不够。如果你能做到这一点，那么你已经做得足够了。
在许可问题上，您需要更好的许可。向 Sitecore 的所有者索要测试服务器的许可证，并告诉他们这是用于测试服务器的。优秀的供应商会意识到，如果他们以这种方式帮助您，您就更有可能续订。或者，向您的财务人员索要另一个 Sitecore 许可证。如果您的基于 Sitecore 的 CMS 网站对您的公司来说是一个非常有用的实用程序，那么另一个许可证不会对您的优势产生太大影响。
When I step back and try to see what you are doing, it is managing the risk of losing business continuity. e.g. If your site goes down, you would ideally want to be able to use your backup to completely and automatically restore the site.
Data storage is not expensive. Really, it isn't. Even when you have a huge data set. And therefore, requiring all developers to use git is a good idea. Many organizations set up a single git server, and you just push/pull to that server. If your solution has good and complete tests, you'll know very quickly if code merges have broken the software. If not, you should probably use a central git server for developers to push/pull, and then a separate release integration server which uses "git fetch" to merge & test changes from the central server.
You have outlined a variety of components of your solution, such as backing up code, data, database, CMS entries, et cetera. However, the overall question you should ask is whether you have gathered enough stuff to be able to completely activate your site just from the backup. If you can't do that, you haven't done enough. If you can do that, you have done enough.
On the licensing issue, you need a better license. Ask the owner of Sitecore for a license for a test server, and tell them it is for a test server. A good vendor will realize that if they help you in this way, you are more likely to renew your subscription. Or, ask your finance people for another Sitecore license. If your Sitecore-based CMS site is such a great utility for your company, another license won't change that benefit by much.
我花了一个小时学习有关 Sitecore 的知识（今天之前从未听说过它，很酷的工具），我想我明白你想要做什么。我将这样做：
git add --all) 并使用“初始提交，版本 XYZ”注释进行提交，其中版本号是您认为当前部署的版本号。请注意步骤 3，其中创建 SQL Server 转储并将其添加到存储库中。这将允许您回滚任何未来对数据库的更改。请记住，每次进行更改时都需要生成新的转储，但仅限于实际更改的架构。序列化您需要序列化的内容，并提交新的序列化以及架构更改。这样，您只需使用 git revert {commit_hash} 即可恢复这些特定更改（当然，不要忘记恢复数据库）。
我希望这会直接或间接地有所帮助。
PS：我不知道你的数据库结构；如果配置与用户数据存储在相同的模式中，那么事情肯定会变得复杂，因为您不能在不丢失新的（并且可能是重要的）用户数据的情况下恢复以前的转储。我习惯了 Ruby on Rails，其中模式修订是针对升级和降级进行编码的；我希望你的框架提供类似的功能。
I spent an hour learning what I could about Sitecore (never heard of it before today, cool tool), and I think I understand what you're trying to do. Here's how I would do it:
git add --all) and commit with an "Initial commit, version X.Y.Z" comment where the version number is whatever you consider the current deployment to be.Note step 3 where SQL Server dumps are created and added to the repo. This will allow you to rollback any future changes to the database(s). Keep in mind you will need to generate new dumps every time you make changes, but only for schemas that actually changed. Serialize what you need to serialize, and commit the new serializations along with the schema changes. That way,
git revert {commit_hash}is all you need to revert those specific changes (without forgetting to restore the database, of course).I hope this helps, directly or indirectly.
P.S: I don't know your database structure; if configurations are stored in the same schema as the user data, it definitely complicates things since you can't just restore a previous dump without losing new (and presumably important) user data. I'm used to Ruby on Rails where schema revisions are coded for up- and downgrades alike; I hope your framework provides a similar feature.