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 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.
Create a New Build Pipeline
The first step in automating our delivery process is to create a new Build Pipeline.
- From the left menu, select Pipelines > Builds;
- Click on the New pipeline button;
- 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.
- 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.
- On the next screen, select Existing Azure Pipelines YAML file.
- 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.
- 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.
- 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.
- Go back to the screen where you can edit your Build Pipeline’s YAML. Click on the ellipses and pick Triggers.
- 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.
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.
- In the left navigation Panel, select Build > Release pipeline
- Click on the New pipeline button.
- When prompted, select the option to start with an Empty job
- Rename Stage 1 to something meaningful like Deploy ARM and close the panel.
- Click on the Add an artifact bubble.
- Select Build as the source, select the Build pipeline from the drop down, rename the Alias to Demo and click on Add
- 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.
- Click on the task link to add tasks to our stage
- Beside the Agent Job label, click on the + sign. In the action panel, search for Azure PowerShell and select it from the list.
- Select the newly added task. Pick your Azure Subscription from the Azure Subscription dropdown.
- In the Script Path picker, select Demo/Demo/CollabSummit/Deploy.ps1 and click OK.
- 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.
- Go back to the Pipeline Overview tab, and select Add > New stage.
- Rename the new stage to something more meaningful, like Deploy DSC and close the panel.
- Repeat steps 8 to 10 above to add a new Azure PowerShell task to our new stage.
- In the Script Path section, select Demo/Demo/CollabSummit/DSC/DeployToAzureAutomation.ps1 as the source script. Click OK.
- 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.
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:
Make sure the above credentials exist, with the same account named.
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!