There are several methods to customize SharePoint. Developers have the option of creating new cloud applications for SharePoint or maintaining legacy full trust code. Coupled with the complexity many organizations have in terms of managing SharePoint customizations across Office 365 and on-premises implementations, developers and solution architects will need to understand how to adjust application lifecycle management (ALM) techniques to support and deploy quality solutions. This series of blog posts will focus on the establishment of development, testing and deployment best practices for on-prem and cloud applications and solutions. This will also include concepts such as continuous integration, release management and automated testing.

If you think that you’ve read this introduction before, that’s true, it’s the description of my session at the upcoming SharePoint Conference:

While working with my co-presenter, Eric Charran (Microsoft), on the session content & demos, I’ve decided to put together a series of posts to cover the same topic in more depth while focusing on the How aspect.

1. Introduction –> You are here!
2. Infrastructure Overview 
3. The Development Environment(s)
4. The ALM Platform(s)
5. The Testing Environment(s)
6. Automated Build & Deployment for Full-Trust & Sandboxed Solutions
7. Automated Build & Deployment for SharePoint-hosted & Autohosted Apps
8. Automated Build & Deployment for Provider-hosted Apps (Azure-hosted)
9. Automated Build, Deployment & Testing for Full-Trust & Sandboxed Solutions
10. Automated Build, Deployment & Testing for Apps
11. Release Management Overview
12. Release Management for Full-Trust & Sandboxed Solutions
13. Release Management for Apps

The full series is based on the best practices and guidance that was put together by some Microsoft folks (Eric Charran, Vesa Juvonen, & Steve Peschka) in this MSDN article.

The article applies common application lifecycle management (ALM) concepts and practices to application development using SharePoint & Office 365 technologies. This series is intended to complement the MSDN article by providing the “How” aspect of doing things. In fact, I’ll be referring to the article in almost every post instead of explaining the theory behind each task / exercise (I’m not a fan of reinventing the wheel).

One thing to note here is that the series is intended to be educational, the lab environment setup (will be covered in the next post) was done in a way that enables you to easily follow along, focus on what we want to achieve without spending too much time focusing on the infrastructure & security side of things. I’ve also broken some rules that are highly recommended to follow in production environments; you will find me ignoring the least privilege accounts principles and using the domain administrator account for setting up almost everything in SharePoint & Team Foundation Server (including all its components), you will also find me combining many services on one virtual machine. This is OK for educational purposes.

However, I’ll be giving you some guidance from time to time on how to setup a real-life Application Lifecycle Environment for SharePoint 2013 & Office 365 SharePoint Online. I’ll also provide you with some links for some of the best resources out there on the internet that can help you on installing & configuring the components needed for building a comprehensive ALM environment for SharePoint 2013 & Office 365. This means that you can still follow along in case you are willing to implement a real-life ALM environment.

Another thing also to note here is that I’ll be explaining how to apply the ALM practices using Team Foundation Server 2013 (on-prem), Visual Studio Online (The cloud offering of TFS) and a hybrid approach. So if you don’t have enough infrastructure or you’re a cloud fan, you can still follow along and choose the option that best suits you.

While you’re waiting for the next post, I’d like to leave you with the following small exercises: