Development Cycles (DevOps) and Office365
Just before the Christmas Holiday’s I wanted to share some insights with the readers of my blog around Development Cycles and Office365.
Development Cycles can also be interpreted as DevOps. Where DevOps is more the culture and practice around the development cycles. According to Wikipedia DevOps can be described as this:
“DevOps (a clipped compound of "development" and "operations") is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.”
As this description on DevOps is quite good how can this be setup for Office365.
As you can see in the above image you will have four environments in a ideal situation.
- [tenant name]dev: Development environment for the developers. When your developers have a MSDN license you could let them work on their MSDN tenant.
- [tenant name]tst:Test environment for the integration test. Every developer will apply his/her changes on the environment using scripts, or by hand (delivered in a document) if the changes can not be scripted.
- [tenant name]acc:Acceptance environment can be used as a test environment for your test users.
- [tenant name}: This environment can be used by the end users.
In smaller environments you could remove the acceptance environment and do the end users tests after the integration tests are finished on the test environments.
In the last year I have also seen projects were they create a test, acceptance and production site collection on the same tenant. When using this approach you won’t be able to test and alter global Office365 configurations.
A downside of the full blown approach is that you will have to manage multiple user stores. Most useful as a user store is Azure Active Directory. A On-premise AD can only be synced to one Azure Active Directory, all other instances will have user accounts as onmicrosoft.com accounts.
Whit scripting deployments you will have to make sure you create and develop the scripts as generic as possible, this makes sure you can reuse the scripts (for example for other clients).
To make PowerShell script reusable you will have to add configuration file this can be done in XML of JSON for example.
One search via Google will deliver a lot of scripts that can be configured via XML. If you ever need help with your scripts just let me know.
As stated above the changes that can’t be scripted, need to be documented in order for a administrator to configure those things during the deployment.
Another important thing about this DevOps setup is to configure the development, test and acceptance tenants as First release tenants. This will make sure you receive the updates on Office365 before you receive them on the production environment, and take appropriate actions if needed.
With help from: