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

2. 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.
Blog:
Talk about our use of CRM – Mostly custom apps providing administrative systems for the university

3. 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,

4. 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

5. 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

6. 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.

7. 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.

8. Lets see it in action

9. 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…!

10. 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

11. Software Developer Toolkit
Install through Visual Studio Extensions and Updates

12. 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.

13. Software Developer Toolkit
Others are available – Jason Lattimer’s

14. Software Developer Toolkit
Others are available – XRM Toolkit
Paid for tool – Very feature rich

15. 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.

16. 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

17. 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’

18. 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.

19. 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

20. 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?

21. UI Testing
Microsoft provide an OPEN SOURCE Selenium based UI Testing framework: EasyRepro

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

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

24. Deployment Definition
We use ADX ALM Toolkit powershell commands

25. Deployment Definition
But you could also use:
Wael Hamze’s tasks VSTS tasks
framework-build-tasks

26. Deployment Definition
Or:
Also Innofactor Shuffle: Preview.html
-devutils-ci-build-tasks
Scott Durow’s spkl:

27. Deployment Definition

28. 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

29. 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

30. 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

31. Questions?