在过去的两年中，我花了很多时间思考“云友好型” SharePoint开发-适用于Office 365的方法和技术，以及需要使用相同的方式设计的本地SharePoint部署原则。现在我们的团队至少完成了20项左右的Office 365 / SharePoint Online实施（并且还在进行中），’我们已经建立了使用Office 365的某些方法。一个很好的例子是创建多个租户来表示开发/测试/生产，以帮助我们的ALM流程，因为Office 365没有测试环境的概念。当然，在SharePoint方面（我在这里关注），您 可以 只是创建一个特殊的网站集-但这并没有’无法为您提供所有全局元素之间所需的隔离。示例包括用户个人资料，分类法和搜索之类的内容。而且由于我们的客户经常要求与这些区域互动的较小的定制，因此“test site collection” idea just doesn’帮我们剪下来。相反，我们采用多租户方式，而我’ve为有类似需求的任何人提倡了一段时间。
当我’在之前的会议上已经讨论过，对于大多数客户/项目，我们的选择是创建单独的开发和测试租约，通常看起来像这样：
It’这不是最重要的一点，但是我们倾向于在这些环境中使用不同的Office 365计划级别-大多数客户使用“Office 365 E3”计划生产，我们’将确保TEST在同一计划上，但通过使用DEV来降低成本“SharePoint P2”（因此没有Exchange，Lync或Yammer Enterprise）。由于我们的大部分开发工作都集中在SharePoint方面，因此通常可以很好地工作。但是，无论您对计划级别如何操作，’同样，使用多个Office 365租约（任何种类）也会带来一些折衷– recently I’一直在考虑减轻这种情况的方案，这些方案大致可以归类为：
- 使开发/测试Office 365租约更像生产
- 寻找针对生产Office 365环境进行安全测试的方法
- 使用子域与＃Office365实施AD集成（用于开发/测试）
- N.B.目录集成为 强制性的 适用于真正的混合部署或使用Yammer Enterprise的地方，但坦率地说，对于避免开发/测试中的其他问题也很有用
- 在开发/测试环境中启用Yammer Enterprise和SSO
- 使用Azure部署插槽为Office 365应用和SharePoint加载项实施开发/测试/生产ALM
多个Office 365租约带来的挑战
当我们谈论开发和测试环境时，实现团队始终需要使它们与生产环境尽可能相似。差异越大，您越有可能’再有一个问题-通常与无效的测试或缺陷有关，这些缺陷或缺陷仅在生产中变得明显。不幸的是，我注意到我们的Office 365项目确实在这里需要权衡。我们确实确实希望有多个Office 365环境用于开发/测试/生产（至少使用Office 365开发人员当前的工作方式），但是很难使其他环境紧密地反映生产。这里’可能有所不同的事物列表：- 通常，目录集成是在生产环境中配置的，但不适用于其他环境
- 换句话说，用户使用“chris@mycompany.com” in production, 但“.onmicrosoft.com”帐户用于开发/测试
- [注：您可能知道此步骤为“实施Azure AD同步”, or “implementing DirSync”使用其以前的名字]
- 对于登录到公司网络（与上述要点有关）的用户，Office 365缺少SSO
- 缺少完整的用户目录
- 在开发/测试环境中，用户配置文件未与AD同步
- Lack of 抱怨Enterprise
- Lack of 抱怨SSO
- 不同的许可证类型（例如生产中的E3 / E4，但开发/测试中的其他许可证）
OK, 但why should I care about these things?
取决于你’重新开发时，其中某些事情肯定会引起问题！根据我们的经验，有一些明显的例子：- It’无法进行端到端测试– we can’t see the “real”用户体验，尤其是跨连接服务的体验，例如Office 365和Yammer
- 在移动设备上的体验不同
- 有时必须以不同的方式编写代码，或者使用“mapping”在开发/测试中-尤其是围绕用户个人资料的内容。例如，任何类型的用户名查找/电子邮件查找/经理查找等等
- 与3的任何集成rd 一方/外部系统如果使用当前用户，则可能无法正常工作’s的详细信息（因为使用了不同的身份）
- 抱怨–缺少SSO意味着两件事：
- 任何标准用法，例如Yammer Web部件或Yammer Embed赢得了’t “just work”-显示一个登录按钮，并且用户必须提供辅助凭据来验证/获取Cookie
- 任何Yammer API代码可能都需要特殊的“mode” –因为您可能正在生产Yammer SSO，但其他地方没有
我们如何应对这些挑战？
因此，如果我们可以改善这种情况，那就太好了。许多问题源于开发/测试环境没有’配置了身份集成和AAD Sync，以及’通常会阻碍建立专用URL域，而Active Directory通常不是’琐碎的。好消息是子域/ UPN后缀方法我’我会在下一篇文章中谈论，让您超越这一点–无论您有多少Office 365环境，您都需要一个URL域和一个Active Directory。在对我们的开发/测试中，这意味着我们在GoDaddy为所有客户/项目注册的URL。我们仅在运行于开发人员机器上的小型VM中运行本地AD。一旦实现了域集成，下一步就是实施AAD Sync，以实际将一些用户从AD迁移到Office 365。 它将运行您选择的一组用户（也许您会将每个开发/测试租赁的一些用户分组到不同的OU中），并将执行在Office 365中实际创建用户的步骤。然后，您可以选择为他们分配许可证如果您希望该测试用户能够登录并使用Office 365功能，并且当用户登录时，实际身份验证将在云中进行。如果要实施Yammer Enterprise和Yammer SSO，现在也可以这样做。目录集成是这两项工作的先决条件，但是解决了这一问题而又没有造成严重的平台/基础架构困扰，这些可能性为我们的开发/测试环境打开了大门。
概要
以便 ’在问题空间上有一点点。最终，在企业级为Office 365开发确实存在一些挑战，但可以克服许多挑战，我们仍将努力寻求可靠的工程实践。接下来的几篇博客文章将介绍其中的一些内容– I’当文章发表时，将在下面的列表中添加链接：谢谢阅读！
没意见：
发表评论