DevOPS for SharePoint Admins

I am sitting in the speakers room at the European Collaboration Summit as I am writing this blog article, just finished giving a talk on DevOPS for SharePoint Admins here in Wiesbaden, Germany. The session I delivered was focused around building a completely automated Continuous Integration and Continuous Delivery pipeline to automate the deployment of a SharePoint 2019 environment in Azure infrastructure-as-a-service, and integrate changes to it. All the files that have been used in my demos are available in my personal Conferences repository on GitHub at AKA.MS/CollabSummit2019. The main idea behind the demos was to deploy a 5 servers environment (1 AD, 1 SQL and 3 SP) to Azure IaaS via ARM templates, and configure Active Directory, SQL 2017 and SharePoint 2019 on them using PowerShell Desired State Configuration. This blog article will describe in details the process involved in setting up the Azure DevOPS environment to support my demo.

Setup a New Azure DevOPS Repository

Our entire demos are going to revolve around Azure DevOPS, therefore our first steps are to go and create a new environment. In order to create a new DevOPS Organization, navigate to https://Dev.Azure.com. I will not cover the entire process of creating a new Org and project as part of this blog post, this is already covered in the following video: https://docs.microsoft.com/en-us/learn/modules/get-started-with-devops/.

In my case, my Organization was created as NikBlogPost.

Create new Organization in Azure DevOPS

Create a New Project

Next step is to create a new project within our new Organization. For my demo, I will be creating a new project named SP2019 Farm and will keep its visibility to Private.

New Azure DevOPS Project

Create a New Build Pipeline

The first step in automating our delivery process is to create a new Build Pipeline.

  1. From the left menu, select Pipelines > Builds;
  2. New Azure DevOPS Build Pipeline

  3. Click on the New pipeline button;
  4. New Azure DevOPS Pipeline Button

  5. As mentioned earlier on, all of our code will be hosted on GitHub. Therefore, when you get to the screen where you need to select the source for your code, we need to pick GitHub.
  6. Import GitHub Source in Azure DevOPS

  7. The next screen will ask you to select the Repository to import the code from. I recommend you Fork my repository inside your own repo before reaching this point. In my case I will select NikCharlebois/Conferences as the source.
  8. Selecting GitHub Repository

  9. On the next screen, select Existing Azure Pipelines YAML file.
  10. Importing existing YAML Build Pipeline in Azure DevOPS

  11. A new panel will popup from the right hand side of the screen, allowing you to select and existing pipeline. Make sure you select the proper branch (in my case Master), and enter the path to the Build Pipeline from your repo. It most likely will be the same as me: /2019 – CollabSummit – Europe/AzureDevOPSPipeline.yaml. Click Continue. The imported YAML template contains a PowerShell Task that will download the Azure Stack Tooling inside the Azure DevOPS Build Agent to validate your ARM templates. This is an important step in ensuring the quality of our build before attempting to deploy anything to our environment. Invalid ARM templates can result in….well, undesired results. Once the template has been validated, it will copy all the files and make them available to our Release Pipelines.
  12. Existing YAML Template

  13. Once the template has been imported, makre sure you update line 24 to reflect your own Azure Subscription and then click on the Run button to test it out and make sure everything is configured properly.
  14. There is a very good chance that running the Build for the first time will result in an error being thrown. This is because we haven’t authorized Azure DevOPS to deploy to our Azure Subscription yet. To correct this, simply click on the Authorize resources button. YOu will need to Queue a new Build once you corrected the issue for it to succeed.
  15. Authorize Azure Resources

  16. Go back to the screen where you can edit your Build Pipeline’s YAML. Click on the ellipses and pick Triggers.
  17. Azure DevOPS Build Triggers

  18. Make sure that Continuous Integration is enabled for your project. This will allow for a new Build to be triggered every time new code is committed to our GitHub repository.
  19. Azure DevOPS Continuous Integration

Create a New Release Pipeline

The final step in our demo is to create a Release Pipeline to actually go an deploy our code to our environment. This is the piece of the puzzle that will make sure the magic happens.

  1. In the left navigation Panel, select Build > Release pipeline
  2. Azure DevOPS Release Pipeline

  3. Click on the New pipeline button.
  4. New Azure DevOPS Release Pipeline

  5. When prompted, select the option to start with an Empty job
  6. Empty job Azure DevOPs Release Pipeline

  7. Rename Stage 1 to something meaningful like Deploy ARM and close the panel.
  8. Azure DevOPS Release Pipeline Stage

  9. Click on the Add an artifact bubble.
  10. Add Azure DevOPS Release Pipeline Artifact

  11. Select Build as the source, select the Build pipeline from the drop down, rename the Alias to Demo and click on Add
  12. Azure DevOPS Artifacts

  13. Click on the lightning icon beside the Artifact bubble to launch the trigger panel. Make sure you enable Continuous Deployment and close the panel. This will make sure that every time we have a successful build, that a new release gets initiated so that our changes can be automatically pushed to our environment.
  14. Click on the task link to add tasks to our stage
  15. Azure DevOPS Release Pipeline Tasks

  16. Beside the Agent Job label, click on the + sign. In the action panel, search for Azure PowerShell and select it from the list.
  17. Azure DevOPS Azure PowerShell Task

  18. Select the newly added task. Pick your Azure Subscription from the Azure Subscription dropdown.
  19. Azure Subscription

  20. In the Script Path picker, select Demo/Demo/CollabSummit/Deploy.ps1 and click OK.
  21. Azure PowerShell Script

  22. Enter -TargetEnvironment “Dev” -TemplatePath $(System.DefaultWorkingDirectory) -ResourceGroupNamePrefix “CS” as Script Arguments, and type in 6.7.0 as the PowerShell Version to use. Click Save, and then OK when prompted.
  23. Azure PowerShell Script

  24. Go back to the Pipeline Overview tab, and select Add > New stage.
  25. Add New Azure DevOPS Release Pipeline Stage

  26. Rename the new stage to something more meaningful, like Deploy DSC and close the panel.
  27. Rename Azure DevOPS Release Pipeline Stage

  28. Repeat steps 8 to 10 above to add a new Azure PowerShell task to our new stage.
  29. In the Script Path section, select Demo/Demo/CollabSummit/DSC/DeployToAzureAutomation.ps1 as the source script. Click OK.
  30. Enter -TargetEnvironment “Dev” -ResourceGroupNamePrefix “CS” as Script Arguments, enter 6.7.0 as the PowerShell version and click Save. Then click on OK when prompted.

Azure Automation

The second task of our Release Pipeline expects an Azure Automation account named CollabSummit to exist in your Azure Subscription, under a resource group named CollabSummit (same name as the automation account). It also expects the following credentials to be defined within your Automation account:

  • AdminCreds
  • SPFarm
  • SPSetup

Azure Automation Credentials

Make sure the above credentials exist, with the same account named.

Summary

We now have all the pieces in place. You can now make code changes to either the ARM templates (e.g. Increase Disk space), or to the DSC template (e.g. Create new SharePoint Web Application) and those changes will automatically be validated and deployed to your environment. To build on this demo, you could also add Post-Deployment approvers to make sure someone have to approve the deployments to the Dev Environment before moving them over to your Quality Assurance environment for example. This is again, a great example of how traditional IT Pros now have to be front and center in any organization’s Application Lifecycle Management process. They now produce just about the same amount of code as traditional developers do!

Leave a Reply

Your email address will not be published. Required fields are marked *