Implementing a Continuous Integration strategy for Dynamics CRM Automating all the things…!

About me Technical Team Lead 20 years in IT, working with CRM since 2011 Lead a small team developing applications for the University of Oxford. ben.walker@it.ox.ac.uk          @bwmodular Blog: http://blogs.it.ox.ac.uk/benwalker/ Talk about our use of CRM – Mostly custom apps providing administrative systems for the university

About this talk I’m not going to show you the definitive CI solution I’m not going to tell you which tools to use I’m going to describe the approach that we have taken, the tools that we use, but where possible I will describe alternative solutions which might work for you Not even going to justify our use of certain tools – sometimes decisions just get made and you go with them if they work We are using Dynamics 2015 on-premise and some of our decisions have been based around this I’m not an expert and we’d consider ourselves to be on a journey rather than having come up with a definitive solution. When I first started to think about CI implementation for Dynamics I really thought it would be difficult, but it turns out to be quite manageable and the right tools are available to support it,

What is Continuous Integration? Every time a developer checks a change in we want to make sure that: It builds We haven’t broken anything It does what it is meant to do We can deploy it to any environment We do this using a Continuous Integration framework Every commit should trigger automated build, tests, release creation and deployment Kind of the holy grail for Agile developers, but the benefits are not just for developers. Better for testers, end users, project sponsors, operations people. A change does not just have to mean a code change, but also a change to the CRM metadata, and this is where CRM is maybe slightly mode difficult than ‘regular’ CI

Why CI? What benefits does having a Continuous Integration strategy bring? Takes the pain out of the deployment process (no more docs for ops) Takes the risk out of the deployment process Standardises the deployment process Shortens the feedback loop between committing changes and deployment to other environments Tests are run after every single commit and after every release – encourages the development of a good automated test strategy, and makes sure each commit is deployable – no missing files Enables you to do small releases – releases become second nature and can be authorised ‘on the bus’ Branching No more writing docs for operations team Typical – end of sprint – all work done – oh but we need half a day to deploy the changes. Also Typical – deployment issues because a file has not been checked in

Branching Can we release a critical bugfix to production without bringing with it all of the unfinished, untested changes which have recently been made in Dev? Not going to be going into branching into detail, but this is traditionally difficult in CRM. Can we release a bug fix through to production without taking all of the other recent changes which have been made in DEV which are not ready, tested. Mention solution packager.

The CI Pipeline In this presentation, I will take you through the journey from the creation of a backlog item to the deployment of code to production Covering the process that we have developed. This is not the only way to do what we are doing, and where alternatives exist, I’ll try and mention them.

Lets see it in action

Covering the process that we have developed Covering the process that we have developed. This is not the only way to do what we are doing, and where alternatives exist, I’ll try and mention them. Lots of green processes. But in a way the whole thing is a test…!

Why VSTS? Brings everything together in one place: Backlog management Code Repository Test management CI server Having everything in one system means there’s a clear and auditable connection between work items, tests, code commits and releases. Free for small teams (up to 5 members) – cheap for HE Others are available…Atlassian/Jira being the main commercial alternative Microsoft have spent a lot of time and effort on VSTS over the last couple of years and it is now really best of breed

Software Developer Toolkit Install through Visual Studio Extensions and Updates

Software Developer Toolkit Actively supported by Microsoft (at last) Provides templates for Plugin and Workflow projects, web resource management and most importantly for us, integration with the Solution Packager Create Early Bound classes within Visual Studio Customization Project allows you to get your CRM solutions under source control – entity and attribute metadata, option sets, etc.

Software Developer Toolkit Others are available – Jason Lattimer’s https://github.com/jlattimer/CRMDeveloperExtensions https://github.com/jlattimer/CrmDeveloperExtensions2

Software Developer Toolkit Others are available – XRM Toolkit https://xrmtoolkit.com/Home Paid for tool – Very feature rich

Solution Packager Part of the CRM SDK toolset. Automatically splits a monolithic solution zip file into individual components. Means that each artifact (Entity, sitemap, Relationship, etc) can be managed individually and brought under source control Each component (apart from plugin and workflow assemblies) is held in a readable XML file, so comparison and versioning becomes easy Can also be used to zip these components back up into a deployable zip file The solution packager is the tool which allows us to break a monolithic solution into discrete components which can be released individually. Will demonstrate this later.

Build definition Define a build definition in VSTS Typically the stages will include: Fetch Source Code From Repository Download packages from NuGet Build Solution Run Automated Unit Tests Publish Artifacts for deployment Typically triggered by a commit to the repository

The VSTS build/release Agent Download the agent from your VSTS instance Authorise with PAT (Personal Access Token) Versions for different OS’s – Windows / MAC OS / Linux Can be given different ‘capabilities’

Automated Testing Automated Testing is Cheap Automated Testing is Quick Automated Testing is Easy An automated test is for life, not just for Christmas Testing helps you stop silly mistakes getting into production Why wouldn’t you do it? CI Helps you test EVERYTHING Once you’ve worked out how to add one Unit tests, adding and running another 100 is trivial.

Unit Testing Cheap – run in millisecond speeds Good unit tests help you think about design Good unit tests help you think about different scenarios Good unit tests help you write good code FakeXRMEasy simplifies this so much – every CRM developer should take a look at this awesome open source testing framework for CRM https://dynamicsvalue.com https://github.com/jordimontana82/fake-xrm-easy

Integration Testing Integration Testing – Does not necessarily mean UI testing – you can test plugins, security roles, view definitions, etc. Not just traditional functional tests, but also testing metadata has been created according to spec For example: Do all entities have an image for the sitemap? Are the right attributes on the Active View? Are Active and Quick Find Views the same? Am I prevented from updating read-only fields? Are the right attributes on the form? How will you regression test when new versions of Dynamics 365 come online?

UI Testing Microsoft provide an OPEN SOURCE Selenium based UI Testing framework: EasyRepro https://github.com/Microsoft/EasyRepro

Integration Test 2 lines of code to test that the code has been deployed and that it does what it is meant to do!

Deployment Pipeline Define the pipeline, authorisation process, tasks, etc

Deployment Definition We use ADX ALM Toolkit powershell commands https://www.adxstudio.com/adxstudio-alm-toolkit/

Deployment Definition But you could also use: Wael Hamze’s tasks VSTS tasks https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci- framework-build-tasks

Deployment Definition Or: Also Innofactor Shuffle: http://jonasrapp.innofactor.se/2017/06/DevOps- Preview.html https://marketplace.visualstudio.com/items?itemName=InnofactorSE.cinteros -devutils-ci-build-tasks Scott Durow’s spkl: https://github.com/scottdurow/SparkleXrm/wiki/spkl

Deployment Definition

Standard Customisation allows us to reuse deployment methods for all projects Standard Powershell Script runs all of our deployments The only thing that changes from one project to another is the environment variables All of our projects reference a standard Deployment project which has all of the common code (used by all deployment pipelines. Then each project has it’s own Deployment project which just holds things like environment variables, and possibly pre/post deployment scripts

We don’t just deploy Dynamics Solutions Web Sites Use MS Deploy SSIS Packages ISDeploymentWizard.exe Database Changes dacpac deployments using sqlpackage.exe All part of the same Visual Studio Solution and all deployed as part of the same pipeline

We are still on our journey Start your journey with baby steps Don’t need to get all of this working in one go Why not start with a few Unit tests Or an automated build process… Or a deployment to a CI environment Agile Mantra – Baby Steps

Questions?