TL; DR;
With the release of Azure DevOps, there’s some new SPFX documentation to set up your CI/CD pipeline in Azure DevOps. Have a look and share your thoughts. Your feedback is always welcome! The Patterns and Practices Initiative also includes a newly reorganized DevOps repository for tools and samples around SharePoint Framework Build and Deploy Practices.
The long story
My journey into the SharePoint DevOps world
I have been working around Application Lifecycle Management (ALM), Continuous Integration (CI), Continuous Deployment (CD) and DevOps practices in the SharePoint/Azure/Office 365 ecosystem for several years. In my experience, whether you’re working alone or as part of a team, adopting proper ALM practices is crucial if you want to produce high quality code.
Historically, SharePoint developers didn’t have many viable options to implement such practices. Building full trust solutions and using XAML build definitions on Team Foundation Servers were more difficult than their “open source stack” counterparts. At the time I was part of the SharePoint on-premises product team for Oceanik, a multilingual product for SharePoint, it was painful and slow, though doable, to automate builds and deployments.
The process improved somewhat with the SharePoint Add-ins development model and Visual Studio Team Services’ new build system (originally called 2015, or JSON builds). At that time, I had the chance to explore these new options and be part of the Attribute product team, which was a semantic analysis product which would automatically tag your documents in SharePoint. With all the learning I’ve been doing, I took the opportunity and started speaking and blogging about these experiences I had discovered.
The power of the community
Great things happen when individuals with similar interests and passions come together. This is exactly what happened to me. Through my speaking engagements, I started building my personal network. Together, we shared our issues and came up with different approaches for solving them.
If you spend enough time in the SharePoint development ecosystem, you are likely to come across some great community leaders in the domain. I’m lucky to have had the chance meet some of them, such as Elio Struyf, Waldek Mastykarz, Andrew Connell, and Vesa Juvonen amongst many others. Following our early encounters, Elio and I started building a Repository to demonstrate how to integrate SharePoint Framework and Visual Studio Team Services to have a better toolchain. The goal was to provide blog posts, which we both wrote independently with no real coordination. It took longer than expected to complete the work as we both hold jobs, are frequent speakers, and have other responsibilities. Fortunately for us, there were several factors that played in our favour:
- In December 2017, Waldek Mastykarz and Andrew Connell created the Office 365 CLI to help you script and automate administrative tasks for Office 365 from any platform.
- In March 2018, we met with Vesa Juvonen, who recommended moving the documentation under the OfficeDev PnP and Official Microsoft documentation
- In May 2018, Microsoft came out with long requested ALM APIs making it much easier to deploy “apps” to SharePoint.
- Shortly after the ALM APIs were released, the Office 365 CLI implemented these APIs making the whole thing much easier
New documentation, new repositories
I would like to introduce you to this new documentation article, which guides you through setting up and configuring your CI/CD pipeline for the SharePoint Framework with Azure DevOps. I suggest you try it out. If you run into any problems, please don’t hesitate to open any issues. More importantly I would like to introduce you to the SharePoint Framework Build and Deploy Practices repository. This is the first step for documenting the ALM process for the SharePoint development ecosystem. What could you add to that? Is there anything you would like to see that is not there today? CircleCI? AppVeyor? Travis? Jenkins?
About this blog
You probably have noticed seeing less content on this blog over the last year. The main reasons being GitHub and Stack Overflow. Those platforms have truly changed the development landscape over the last few years. From my perspective I think it is much more beneficial to the whole community if the solution that would have been in a blog post is directly incorporated in an open source project. Same if the knowledge answering this question or revealing that bug is shared on platforms that have more exposure, mechanisms to triage/dispatch/address it, etc.
Conclusion and final thanks
This has been an amazing journey which allowed me to learn a plethora of things as well as meet and get to know peers. In addition to the people that I mentioned through the article, I’d like to thank my friend Haniel Croitoru who proofread not only the documentation but also this article.