CRM Software Quotes
CRM search»CRM Implementations»DevOps Toolchain for Microsoft CRM

 Chuck SchaefferDevOps Toolchain for Microsoft Dynamics 365

 
 By

Agile CRM software implementations configure and create more software in shorter cycles. DevOps responds to this increased pace and frequency by automating the build, test, integration and deployment processes. As stated by Forrester analyst Kurt Bittner, "If agile was the opening act, continuous delivery is the headliner."

Continuing to follow application lifecycle management (ALM) processes built for waterfall deployments, and built upon labor-intensive tests, low-level migration scripts, manual interventions and as much time as you need, will fail to keep up with agile implementation methods and negate business benefits such as rapid and flexible response to change, the frequent delivery of incremental software releases, outcomes that better align with business objectives and faster time to market.

This is why Continuous Integration, Continuous Test and Continuous Delivery tools and processes are required. To work effectively, these steps must be dynamically linked and automated with a DevOps playbook and workflow automation.

A Gartner report advised that, "DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain." In this article I'm going to focus on a DevOps toolchain used for Microsoft CRM software implementations. I'm not going to try to identify all the potential toolchain tools, but will share many of the tools that have contributed to successful Dynamics 365 CRM DevOps programs. DevOps frameworks vary based on objectives, process, technology and maturity. The CRM DevOps toolchain shared here is something that has worked for me over several large CRM software deployments.

DevOps Toolchain for Microsoft CRM

CRM DevOps toolchains are built upon technology stacks that align with the CRM software. That means Team Foundation Server (TFS) or Visual Studio Team Services (VSTS) for Microsoft Dynamics 365 CRM. TFS is an on-premise solution. It can be hosted, but that shouldn't suggest it's designed for the cloud. VSTS is designed for cloud delivery. As most Microsoft CRM buyers are choosing to go with CRM Online, I'll focus most of the toolchain foundation on VSTS.

Agile Development is the start of the continuous build process. Agile or Scrum sprint backlogs define software increments to be built over short but high velocity iterations. The sprint increments become the output which upon check-in to version control kick off the Continuous Build process.

  • Visual Studio Team Explorer or Team Web Access are the initial access and project visibility tools. While the VSTS Web Access portal can provide end to end management for all agile and DevOps team members, developers will most likely instead use VS Team Explorer to connect with Team Services.
  • Team Rooms are online chat rooms that provide central forums to be shared by non-technical and technical team members. Team rooms facilitate a central messaging and document repository, a place to record daily scrums or other meetings, and a real-time view of user story events and progress. For example, when a dev team member accepts or advances a user story, the user story status is automatically updated and a message is inserted in the team room. Because of the tight integration between Dynamics CRM and Yammer, agile teams sometimes prefer to use Yammer for online collaboration. While Yammer may offer advantages such as better support for a broader audience, the lack of integration and support for agile process events reduces any benefits.
  • Team Foundation Version Control (TFVC) can be used for centralized source code version control. This method uses a centralized file server to sync software snapshots with dev clients.
  • Git is an alternative to TFVC to be used for distributed version control. This method does not require a central server as each dev client clones the latest software repository with history.
  • Check-In Policy Controls are rules configured in VSTS that enforce dev check-in and similar policies. These can be helpful controls to ensure dev staff compile, comment and run tests (such as Code Analysis) that verify code quality before check-in.
  • Build alerts can be user-configured notifications directed to SOAP endpoints instead of email addresses. These alert types can be configured to monitor the build and trigger an action if the build fails.

Continuous integration is the frequent integration of new and updated code with the central code repository. The goal is to automate error free builds that are then picked up for deployment in designated environments.

Developers upload their code to a build server which merges their code with the code base, compiles the latest version, initiates automated quality control processes (which generally include unit tests, integration tests, static and dynamic tests, performance tests and other checks) and delivers a package for release.

Continuous integration solves the long-time problem of 'integration hell.' The longer a programmer holds onto his copy of the central code base, the more likely he will incur merge conflicts when his branch is checked back in to the source code repository. Continuous integration mitigates this problem by promoting frequent integration, often multiple times per day. Software quality is improved and the DevOps deployment process is accelerated when merged code quality control measures are performed on a continuous basis instead of the more common practice of applying quality control near the end of the process. Continuous integration is one step in continuous delivery.

The continuous integration process and tools will flag code defects and failed builds more frequently in order to fix and eliminate these issues at the source. However, without a change in culture which makes those errors highly visible and encourages team members to take responsibility for their quick resolution, the tools alone will not deliver the needed impact.

  • In VSTS you can create a build definition to support your continuous integration build. The build definition can specify the build steps and follow-on quality control tests; run on a build server or the hosted build agent; and initiate on demand, on a schedule or upon every check-in.
  • Feature toggles are an alternative to branching that can aid DevOps programs by accelerating continuous integration. Branching is used for feature isolation, bugs or hotfixes. It's also used when developers need to work on multiple things at the same time, or check in incomplete code. Distributed version control systems can accommodate branching, but the process incurs challenges such as merge conflicts. Feature toggles use simple if statements to hide or display code. When the feature is complete, the if statement is removed.
  • SonarQube is a continuous inspection code quality tool. This open source product works well with C# code and examines architecture, code rules, duplication, unit tests, defects, comments and complexity. Where most continuous testing tools operate at points in time on each programmers' computer, SonarQube initiates upon check-in on the build server. Over time agile dev projects accumulate technical debt. Failing to measure and remediate that debt decreases programmer productivity and ultimately leads to significant refactoring. SonarQube is particularly well suited to identifying technical debt. Its SonarQube Quality Model measures technical debt and suggests steps to resolve.
  • Continuous integration testing generally includes QA staff using the Test Hub in the Web Access portal. Tests are organized in hierarchies with test plans at the top, and then cascading down to test suites which group test cases. Requirements-based Test Suites link back to user stories, and query-based Test Suites can group test cases in user defined ways. Test plans can be copied and modified as needed for each successive sprint.
  • Microsoft Test Manager has overlap with Test Hub but is more commonly used by DevOps teams and QA professionals. Like Test Hub, MTM comes with Visual Studio and manages test plans, test suites and test cases. However, unlike Test Hub, it's a desktop app that better integrates with the local operating system as its running on premise and not from the cloud.
  • The Coded UI test builder and editor are built upon the Microsoft UI Automation API and support automated GUI testing. The tool records your actions, permits defined values in specified fields and generates the code for playback and testing.
  • Load Test Hub is a Visual Studio service that runs URL-based load tests. Team Services can record and replay cloud-based load tests for performance and scalability analysis. Because the test is normally performed from a single agent and IP address, issues such as caching, latency, hops and jitter will impact test results. Microsoft also offers Dynamics CRM Online performance and scalability testing for a fee. While the Microsoft test offers greater assurance, the Load Test Hub is a good early analysis step.

DevOps Toolchain for Microsoft Dynamics 365 continued >>

DevOps for CRMDevOps CRM ToolchainDevOps for CRM

 

 

Share This Article


Quote

"If agile was the opening act, continuous delivery is the headliner."

— Forrester's Kurt Bittner

 

Related Articles

 

 

CRM Quote

Follow Us
social
social
social
social

crm search

Home   |  CRM  |  Sales  |  Marketing  |  Service  |  Call Centers  |  Channels  |  Resources  |  Blog