3 - Dynamics 365 Customer Engagement - Continuous Integration
3 - Dynamics 365 Customer Engagement - Continuous Integration
3 - Dynamics 365 Customer Engagement - Continuous Integration
Engagement - Continuous
Integration
Microsoft Services
Module Overview
• What is Continuous Integration?
• What are the Benefits?
• Team Development workflow example
• Azure Pipelines for build and testing
• Applying Continuous Integration to Dynamics
Continuous Integration Health Check
• Source control is the sole source of truth?
• Development environments are disposable?
• Development occurs in isolation?
• What testing do you automate?
• How does your team collaborate, share risks, innovate,
and learn?
What is Continuous Integration?
• The process of automating the build and testing of code
every time a team member commits changes to version
control.
• Committing code triggers an automated build system to
grab the latest code from the shared repository and to
build, test, and validate the full master branch
• Encourages developers to share their code and unit tests
Continuous Integration Benefits
1 2 3
S S
Build Release
SCM
Stage Stage
S S
Test / Integration
Just in
time
Development
instances
Considerations
• Are automated builds only triggered on certain branches?
• PowerApps checker
• Solution analysis can result in long running processes
• Run on every commit or only when merging to development or master?
• Setup pipeline for self-service testing and validation for out of cycle runs?
• To gate deployments or not?
Considerations
• What is the most effective way to isolate development?
• Avoid shared development instances
• Developer isolation is preferred
• How do we merge solutions?
• In source control
• Ideally developer work should not overlap, and check-ins should occur regularly on
smaller sets of changes
• Do we employ the use of patches to seal change history?
• How do we track patches?
• Adding patches increases branching and merging complexity
• Might be necessary for gated deployments (touch on this later)
Azure DevOps
https://aka.ms/YAML
Azure Pipelines Overview
Azure Pipelines
Azure Repos
Azure Artifacts
https://azure.com/devops
Terminology
Pipeline
• A pipeline defines the continuous integration and deployment process for your app. It's made up of one or more
stages.
• It can be thought of as a workflow that defines how your test, build, and deployment steps are run.
Agent
• When your build or deployment runs, the system begins one or more jobs.
• An agent is installable software that runs one job at a time.
Job
• A stage contains one or more jobs. Each job runs on an agent.
• A job represents an execution boundary of a set of steps.
• All the steps run together on the same agent.
Environment
• An environment is a collection of resources, where you deploy your application.
• It can contain one or more virtual machines, containers, web apps, or any service that's used to host the application
being developed.
Terminology
Trigger
• A trigger is something that's set up to tell the pipeline when to run.
• You can configure a pipeline to run upon a push to a repository, at scheduled times, or upon the completion of
another build.
Stage
• A stage is a logical boundary in the pipeline.
• It can be used to mark separation of concerns (e.g., Build, QA, and production).
Step
• A step is the smallest building block of a pipeline.
• For example, a pipeline might consist of build and test steps.
• A step can either be a script or a task.
Variables
• Variables give you a convenient way to get key bits of data into various parts of the pipeline.
• The value of a variable may change from run to run or job to job of your pipeline.
Build Agent Setup – Classic Editor
• Visual Designer (Classic
Editor)
• Visual Designer can be
exported as YAML
• Review the marketplace
for first and third-party
extensions
Build Agent Setup – YAML
• A YAML based
approach is
recommended
• Task assistant provides
familiar experience from
the classic editor
Exploring CI for Dynamics
• Complexity can vary
• In the most basic form,
• Use solution packager to pack solution stored in repository
• Publish solution as an artifact
• Not a lot going on and not a great value add
Jobs of the Build Stage
• Build
• Build • Build
Source Web • Pack
Plugins
• Unit Test Resources
• Unit Test Solution UI Tests Tests
• Publish
• Publish • Publish
• Publish
UI Tests
Exploring CI for Dynamics
• Avoid storing pipeline configuration code in the same
repository as your Dynamics solution, plugin, web resource
or other code.
• Consider storing sensitive information in Azure Key Vault
• To simplify your setup complexity use existing tasks from
the marketplace
Demo: