Sitecore Cloud Migration from On-Premise to Microsoft Azure Platform-as-a-Service (PaaS) — Part 3: Managing All the Tasks
The Different Development Teams
There are multiple development teams working on the same Sitecore web application which I am migrating to Azure. The focus of the different teams are roughly as follow:
- A team that is currently reworking a major part of the web site that helps drives the company’s main revenue stream
- A team that focuses on a paid membership system, and the Sitecore web application is only one of the multiple web applications the membership system is built upon on. This development team is based offshore and its members are the company’s employees.
- A small team that focuses only on one particular product that the company offers. The product makes up of a large enough percentage of revenue annually. This team is also made up of the company’s employees.
- A Business-As-Usual (BAU) team, which focuses on bug fixes, incident supports, small to medium new features, and small improvements of the Sitecore web application
- Azure Migration team
All the teams adhere to the same release cycle, which is approximately every 2 weeks of a sprint cycle. User stories, technical stories, technical tasks and bugs are released to production as long as they are completed before the release date.
The Azure Migration project is one of the many major focus of the company. If any developer outside of Azure Migration Team is available in any sprint cycle, and has the technical capability to help out, that developer will be assigned task(s) from the Azure Migration project.
Agile / Scrum Theory
I am not going to get into the details to discuss / argue / convince whether the the Azure Migration team is really running on Agile and / or Scrum at all in this blog post. Rather, I would like to focus on how the tasks are broken up and prioritised.
One of the most prominent way to illustrate Agile / Scrum is the infamous Mona Lisa iterative / incremental delivery approach.
Due to the possible variation of team resources that may be available per sprint cycle, it is very important to ensure that user stories, technical stories or tasks must be broken down into the smallest deliverable chunks as possible, whilst ensuring value can be added to the solution. Tasks that cannot be broken down due to various reasons would be dedicated to the Azure Migration team only.
To reduce as much differences between the current On Premise setup to PaaS as possible, the completed tasks are also delivered to the current On Premise setup, so that the multiple teams that manage the application can also have some time to get used to potential changes when the switch to PaaS is made. Majority of those tasks will also form part of a base setup for future Sitecore PaaS / IaaS solutions. The changes will also allow multiple rounds of regression testing to be completed if required, and to ensure whatever that was implemented will definitely not produce any problems in PaaS as they are already being utilised for a long period of time before the PaaS switch.
In theory, the visual and functional part of the web application should be exactly the same before and after the Azure Migration is completed. Luckily, unit tests (both front end and back end), visual comparisons (applitools), functional tests and health tests are continuously updated and run already. At some point, I can run all of those tests in parallel to the current production environment, and there should be no differences at all when comparing to the PaaS environment.
Themes
After conducting lots of researches, and with ongoing feedback of other Sitecore teams implementing Azure PaaS in the Sitecore community, I have come up with the following themes which all the tasks fall into:
- Disk Space / IO
- Custom Cultures
- Logging using Application Insights
- DevOps lifecycle ie Continuous Integration, Continuous Delivery, Continuous Testing, Continuous Monitoring.
- Environment Provision, which also includes decommissioning non production environments outside of working hours to reduce operating costs
- SOLR Search Service
- Porting over current schedule tasks into Azure Web Jobs
- Performance / stress testing
- Operations, which includes setting up external monitoring, IP address whitelistings
Not every single tasks that falls into the category might make it to the very first time the switch to Azure PaaS. I will highlight some of the specific tasks in future blog posts for each of the above themes.
