Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I have always found that plans are useless, but planning is indispensable.
I found this articles on Microsoft Dynamics CRM and the application life cycle, I thought I would share them. These
The articles above got me thinking about the CRM deployments best practices but which focuses on manual deployments and the best practices involved with that.
Another consideration is organising your solutions – CRM 2016 – What’s the best way to organise solutions in Microsoft Dynamics CRM
make surec ustomizations are kept at a high standard
Microsoft Dynamics CRM Customization Best Practices
When I wrote the article on deployment best practices I only worked on projects which deployed projects manually and I had no experience with the solution packager.
I believe automating the deployments would be the best practice because manual deployments are
The question CRM developers should ask is why are most CRM projects not using the solution packager?, it‘s best practice, it saves time, fewer deployment mistakesso why isn’t it standard practice.
Companies and project managers don’t give time for the team to learn and setup the solution packager because it‘s time spent on infrastructure with no business value. Setting up the solution packager for Dynamic CRM projects is short-term pain for long-term gain.
The solution packager allows you to commit your customisations into source control because it breaks down the customisations into xml files.
One of the reasons I moved to Capgemini is because they have a DevOps team for Dynamics CRM projects. Capgemini focus on delivery high quality large difficult projects, to do this you need to think long-term, focus on keeping quality of customisations high, keep technical debt low and automate where you can.
Now I have worked on a project with DevOp, the solution packager, continuous integration I am of the opinion all Enterprise CRM projects should have this setup.
Having a dedicated DevOps team or someone who has learnt to use the solution packager and creating builds will help the process. Building automated build environments takes experience and the job falls to a developer they will take time to get up to speed in the same
The solution packager is a powerful tool which can automate importing solutions between environments but it has a number of other useful benefits.
Importing solutions is a boring and time consuming which should be automated to not waste developers time, allowing developer to concentrate on creating customisations.
If you can automate a boring task then you should automate it #HoskWisdom
The solution packager enables scripted automated deployments and some other benefits
The solution packager gives you control and visibility on what changed, who changed it, what it was for and when. The solution packager shows CRM changes, including customisation change (form, fields, views) gives visibility of those changes. This enables CRM developers to check in changes to tasks and stories
The solution packager can be scripted and incorporated in builds using Visual studio Team Services (VSTS). Automating the build processs allows data to be imported into different CRM environments (a step which is often missed or done incorrectly). Automating data import keeps the guids the same between environments. CRM 2016 – The importance of keeping the same guids between CRM instances
Here is a collection of Solution packager articles if you want to learn more
The article started out with links to the ALM – CRM lifecycle but morphed into clarifying the purpose and benefits of using the solution packager to automate solution deployment.
The solution packager allows automated builds/continuous integration which can save time and reduce import errors. The solution packager breaks down CRM customisation to XML files which can be checked into source control (VSTS/GIT) and linked to individual tasks and stories.
Solution packager isn’t easy to configure but the benefits are worth it, companies and projects should see it as an investment in quality, long-term benefits which pay dividends on large CRM projects.
Business Applications communities