Sitecore 环境
我们组织的网站正在迁移到 Sitecore CMS，但我们正在努力以某种方式为开发人员 (4)、设计师 (4)、QA 人员 (3)、作者 (10-15) 和审批者 (4-10) 设置环境在他们可以独立工作的地方，我知道会有依赖性，但想法是尽量减少它。
以下是一些规则：
1）无论谁负责变更，他们都应该做所有事情，直到并且除非存在任何依赖性。
2）如果一个团队正在开发一项功能，那么它不应该停止或影响其他团队的工作。例如，如果 QA 正在测试该功能，那么 Derringers 和开发人员应该继续研究同一功能以获取新的增强功能。
与环境相关的问题：
1) 设计师将在哪里工作？我的意思是他们将在哪里添加 html、js 和图像？在哪个服务器上？在 Sitecore 中？在源代码管理 (TFS) 中？
2）设计师和开发人员应该如何合作？我知道开发人员将在 Sitecore 中的本地计算机上工作。并将他们的工作推广到集成服务器，但他们将如何获得设计师的东西？假设该功能已经成功投入生产，现在只需要图形设计更改，比如说字体样式和一些图像，那么设计师应该在哪里进行这些更改呢？在哪个服务器上？之后，该 Sitecore 实例将如何与其他 Sitecore 实例同步。对于设计更改，我不希望开发人员推广任何代码或文件。
3) 同步 Sitecore 环境/数据库最安全的方法是什么？意味着无论发布到生产网站中的是什么，我们都需要返回到 DEV、QA 和 UAT 环境中。
我们不想对代码、html、js 和图像文件进行任何手动升级。有没有办法通过工具或 Sitecore 命令自动执行此类操作。我个人不喜欢 Sitecore 软件包。
4）你知道什么好的参考资料吗？在哪里可以找到类似问题的答案？有什么网站、书籍、博客吗？
我知道一篇文档“Understanding Sitecore Deployments 6.2”，但设计人员部分以及如何同步不同的环境并没有在那里讨论。
谢谢。
Our organization's website is moving to Sitecore CMS but we are struggling with setting up the environments for Developers (4), Designers (4), QA persons (3), Authors (10-15) and Approvers (4-10) in a way where they can work independently, I know that there will be dependencies but idea is to minimize it.
Here are couple of rules:
1) Whoever is responsible for the change then they should do it everything until and unless there is any dependency.
2) If one team is working on one feature then it shouldn't stop or effect other team's work. For example, if QA is testing the feature then Derringers and Developers should continue their work on the same feature for new enhancements.
Questions related to environments:
1) Where the Designers will work? I mean where they will add their html, js and images? On which server? In Sitecore? In Source Control (TFS)?
2) How the Designers and Developers should work together? I know developers will work on their local machine's in Sitecore. And will promote their work to Integration server but How they will get the Designers stuff? Let suppose the feature has gone into production successfully now only Graphics Design changes are required, let say font styles and some images then where Designers should make these changes? On which Server? And after that how that Sitecore instance will sync with other Sitecore instances. And for design changes I do not want developers for promoting any code or file.
3) What is the safest way to sync the Sitecore environment/databases? Means whatever has been published into production website, we will need back in DEV, QA and UAT environments.
We do not want to do any manual promotion of code, html, js and image files. Is there any way to do these kind of things automatically via tool or Sitecore commands. Personally I do not like the Sitecore packages.
4) Do you know any good reference? Where I can find answers of similar questions? Any website, book, blog?
I know one document "Understanding Sitecore Deployments 6.2" but designers part and how the different environments will be synchronized are not discussed over there.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的设计师无需访问 Sitecore 来构建静态标记/js/css/图像，但要将其合并到 Sitecore 中，您需要有人通过添加具有标记和引用的子布局或渲染来集成它css/js/图像。如果您将设计人员和开发人员分开，那么向他们解释您正在使用 ASP.NET Web 表单环境通常会有所帮助，因为需要牢记一些特殊注意事项（例如控件 ID 和表单使用）。让他们与您的开发人员共享源代码控制是一个巨大的优势，因为如果双方工作相切并进行单独更新，它可以限制可能需要完成的返工量。
有必要概念化静态内容和动态内容之间的区别。如果您需要进行涉及更新标记/css/js 的“设计更改”，那么您将需要以与开发人员相同的方式在软件开发生命周期中推动该更改。事实上，开发商最好这样做。如果您需要进行本质上更“动态”的更改，并且已开发用于 - 例如，在某些情况下通过使用富文本编辑器字段更新文本、链接、图像，甚至 CSS，您当然可以让设计师来完成。他们将像任何使用 CMS 的人一样成为“编辑者”。他们在编辑过程中的参与程度很大程度上取决于您将“基于内容”的范式延伸到什么程度。如果您愿意，您可以让所有页面只公开富文本编辑器字段，但从 Sitecore 的角度来看，这将是极其糟糕的做法。
查看 Hedgehog Development 的 Team Development for Sitecore 产品。
有许多由 John West、Alex Shyba 等领先的 Sitecore 开发人员提供的 RSS 提要。还有很多阅读列表。
有许多
There’s no need for your designers to have access to Sitecore to build static markup/js/css/images but for that to be incorporated into Sitecore you will need someone to integrate it by adding sublayouts or renderings which have the markup and reference the css/js/images. If you have separated your designers and developers it is normally helpful to explain to them that you are using a asp.net web forms environment as there are special considerations to bear in mind around that (e.g. control IDs and form usage). Having them share source control with your developers is a massive advantage as it limits the amount of rework that may need to be done if both are working in tangent and making separate updates.
It's worth conceptualising the difference between static and dynamic content. If you need to make a "design change" which involves updating markup/css/js then you will need to push that change through your software development lifecycle in just the same way as developers do. In fact, it would be best for the developers to do that. If you need to make a change which is more "dynamic" in nature and has been developed for - e.g. updating text, links, images, even css in some cases through using Rich Text Editor fields you could of course have designers do it. They would be "editors" like anyone using a CMS. How much involvement they have in the editorial process is very much up to how far you stretch the "content based" paradigm. If you wanted, you could have all your pages just expose a rich text editor field but that would be extremely bad practice from Sitecore's perspective.
Check out a product called Team Development for Sitecore from Hedgehog Development.
There are many RSS feeds by leading sitecore developers such as John West, Alex Shyba e.t.c. There are also lots of reading lists out there.
此插图
显示了一种组织环境的方法，避免重叠和阻塞。回答您的问题：
1 和 2) 开发人员和设计人员都在本地计算机上工作，使用本地 Sitecore 实例。他们使用 TFS 作为源代码控制系统，以便可以相互集成他们的工作。通常，设计师更多地从事 CSS、Javascrips、图像、子布局（标记）方面的工作，而开发人员则更多地从事代码本身的工作。我们有一个持续集成服务器（例如：TeamCity），将更改部署到 3 个不同的环境 - CI 服务器（用于构建运行状况检查）、QA 服务器（用于 QA）和 Prod 服务器（用于内容编辑和公共访问）。例如，当设计人员必须修复布局问题时，他将在本地计算机上执行此操作，然后将更改提交到 TFS。下一步，TeamCity 将把更改部署到 CI 服务器，如果构建正常，QA 人员可以触发构建并测试修复。如果一切按预期工作，有人可以触发生产服务器的构建，并且修复生效。
您有另一个图表
显示有关如何设置生产服务器以分离内容创作和内容交付的详细信息 - 此处是一个搜索，我发现了几篇关于设置此功能的博客文章：Sitecore 内容创作交付
3) 您需要 TDS（Sitecore 团队开发）- 使用此工具对来自一个的项目进行序列化/反序列化Sitecore 实例到另一个。然后，您可以将序列化文件保存到 TFS 并在团队和环境中共享。好处是您可以使用 TeamCity 自动将项目推送到 CI/QA/Prod 环境；
4) Sitecore 的主要信息来源是他们的 SDN - 您可以免费注册（或者如果您有 Sitecore 许可证，则可以拥有扩展帐户）
This illustration
shows a way to organize your environments avoiding overlaps and blockings. Answering your questions:
1 and 2) Both Devs and Designers works at their local machines, using local Sitecore instances. They use TFS as the Source Control system so they can mutually integrate their work. Usually Designers works more in CSS, Javascrips, Images, Sublayouts (markups) and Developers at the code itself. We have a Continuous Integration server in place (Ex: TeamCity) deploying changes to 3 different environments - CI Server (for build healthcheck), QA Server (For QA) and Prod Server (for content edition and public access). When, for instance, a designer has to fix a layout issue, he will do that at his local machine, then commit changes to TFS. Next step, TeamCity will deploy changes to the CI server, if the build is Ok the QA person can trigger a build and test the fixes. If everything is working as expected, someone can trigger the build to the production server, and the fix goes live.
You have this another diagram
showing details on how you can setup your Production server to separate Content Authoring and Content Delivery - Here is a search I found several blog posts on setting this up: sitecore content authoring delivery
3) You need TDS (Team Development for Sitecore) - Use this tool to serialize/deserialize items from one Sitecore instance to another. Then you can have the serialized files to TFS and share across the team and environments. The good thing is you can use TeamCity to automatically push items to CI/QA/Prod environments;
4) The main source for info on Sitecore is their SDN - You can register free (or have an extended account if you have a sitecore license)