Overview
HSO ProServ develops and maintains several IP solutions on Dynamics 365. This includes projects360, aec360, accounting360 and consulting360 which are add-on solutions extending Microsoft Dynamics Finance and Operations core modules in particular Project Management and Accounting module. HSO ProServ ISV portfolio also consists of aec360 and legal360 for Dynamics Customer Engagement and other accelerators. The purpose of this document is to provide Customers and Partners deploying the HSO ProServ solutions, an in-depth view of OneVersion software update policies that are adhered to in line with Microsoft’s recommended best practices. Note: projects360 for project operations has the same code base of projects360 with additional integrations, the core solution of projects360 will also follow the OneVersion update policy as described here.
Supported Versions
N and N-1 versions are supported
- Our standard policy is to support One major version and one minor version (ex: 10.0.11Maj, 10.0.12Min, 10.0.13Min, 10.0.14Min, 10.0.15Maj, we would support 10.0.14 and 10.0.15)
- Additionally, Hot fixes are supported for P1 issues on any two Major versions (in the above example we will release a HF for P1 on 10.0.11 or through 10.0.15)
- We have four Major releases in a Year that coincides with Microsoft’s OneVersion release. All other Minor updates are only compatibility releases (that is if we find a breaking change from Microsoft, then we release a minor compatibility release). If no breaking issues, then we don’t release a compatibility release but just issue a statement that the current version is forward compatible.
- The product team, occasionally vary the schedule for a major release date and push it for a week or two due to other priority commitments (supporting go live Customer, HF commitment etc). However, we will work closely with clients on their update plans and will support an early release with follow-on hot fix if needed.
Exceptions for P1 Issues
P1 definition: user wide impact, has not potential work arounds.
In general, P1 issues are deemed high-priority and are resolved as soon as possible. The first step in troubleshooting P1 issues is to recreate the issue on non-Client environment. To accelerate the root cause, the troubleshooting of the issue is done directly on the Clients development environments. Once the steps to recreate are determined, they are captured in DevOps and further investigated for resolution. Developers resolve the issue, a build kicks in the update to a QA environment with the code fix and tested before the P1 issue resolution is handed off to the Client.
Release Cadence
There are two major releases and several minor release. Major release contains ‘big rock’ work items. These are features that are significant product investments. Minor releases contain ‘small rock’ work items, quality updates and cumulative releases.
Here is an example of the release cadence shared from time to time.
Product Team
The UO product comprises of developers, technical architects, product champions and functional consultants. The Product Steerco team is responsible of the future roadmap decisions, funding and supporting other strategic decisions.
Installation
The installation of the deployable package is straightforward, in that, the Client subscribes to an LCS project. Users are notified when new version updates are made available along with Release notes. The release notes detail the net new features and quality issues that are addressed in the release. The deployable packages are stored in the LCS asset library. The Client has the option of using the deployable package or a model file for deploying software. Note: not all Client get access to the model files and is determined based on the Client contracts.
Product Team Setup
The product team is comprised of core IP development teams supported by extended teams for ongoing Client support, Power Platform, Power BI development and Regression Automation teams. Each team is fundamentally responsible for a specific set of tasks. For instance, core IP team is only responsible of net new feature development based on Client feedback. Feedback from various clients is captured in DevOps as a User Story. During sprint planning activities, the core team supported by the principal architect prioritize the features to be developed for the upcoming release. The cycle continues every sprint. There are several sprints before the official Release of the new version.
DevOps Branch Strategy
Product baseline code is checked into DevOps repository. Each branch serves a release cadence. The features developed are merged between branches along with any ad hoc hotfixes that are released to Clients. An automated build system generates a build on demand and deploys code to various QA environments for validation of features. Developers connect using local VMs and synchronize code with DevOps repository (get latest) every day. Developer checks out Development branch, writes modification code and tests in the local hosted dev boxes
- Developer checks code into Development branch
- Dev Lead forward-integrates the change into Mainline
- Mainline branch is deployed to Mainline build -environment via Azure DevOps. Automated tests are run as part of build process. Manual testing is also performed here.
- Release manager, releases package to QA environment via continuous integration option of Azure DevOps.
- Release manager creates a cut-off branch to the Release branch
- Managing separate Release branches based on the platform compatibility to support Customers on different platform versions
Unit Testing and Code Quality
In this process, Developer concentrates on the code quality and the development standards as listed below (example):
- Quality code implementation approach
- Performance based code implementation
- Avoiding redundant code
- Proper naming conventions
- Best practices-based development
- Development standard at each object level (AOT)
- Declare variables as locally as possible.
- Check the error conditions in the beginning; return/abort as early as possible.
- Have only one successful return point in the code (typically, the last statement), with the exception of switch cases, or when checking for start conditions.
ALM Lifecycle and Feature Prioritization
ALM lifecycle of the IP starts with the Steerco meeting with the Customer Advisory Board (CAB). The CAB is a list of industry specific representatives from various HSO ProServ Client portfolio. The CAB team along with the Product team meet once every quarter to chart out road map items. All feedback from CAB is tracked as DevOps work items and goes through the sprint planning meetings for design and development of the features.
Hotfix Requests
Hotfix requests are only supported and released for on ‘n’ and ‘n-1’ versions. All hot fix requests are first qualified for priority and severity of the incident. If the issue has a work around, the fix is only resolved in an upcoming version. If a hot fix request is qualified (has wide impact to many users, financial impact like invoicing, implementation teams finding showstoppers during UAT etc). The hot fix is released on the version that it is requested in and then updated to the main branch so future releases includes the one-off fix.
Frequently Asked Questions
- When are the main releases?
During Spring, Summer, Fall and Winter in line with the major releases.
- What is my downtime on the ISV updates?
Depends on the number of ISVs that are deployed together, typically an update can be achieved within the 1-2 hour window.
- How do you ensure quality of updates?
We run RSAT regressions on every major release and do a subset of key test scripts for the minor compatibility releases. We have over 150 test scripts that are automated and used in regression testing. These test scripts are completely run for every major release and the exit criteria for any release is a 100% pass rate. For minor releases, the criteria is slightly different, we will release if the pass rate is in the 90% range and if there are no P1 issue identified.
- What is your guidance to customers who are taking Microsoft updates? Do you require them to take your ISV update?
We encourage them to take all ISV updates available at the same time as the Microsoft update. It saves time on testing, environment deployments, etc. Most all do. If someone didn’t want to, we would allow them skip. Our published version supportability is similar to Microsoft’s one and then we just work with customers that have any reasons/issues for falling behind.
- So, a customer can take MSFT update and still run the current version of ISV they are using in production?
We do support forward compatibility if there are no breaking issues from Microsoft in an update. So, a customer could take a Microsoft update and stay on our lower version update. If we have released a major version or compatibility update, we prefer they take it but will work with them to solve the situation either way.
- Where can I find more help about the product?
- How can I reach to the Product team to share my ideas, feedback or issues.
- For feedback and ideas, email to – Product Ideas
- For issues, email to – Product Support