I have always found that plans are useless, but planning is indispensable.
–Dwight Eisenhower
I found this articles on Microsoft Dynamics CRM and the application life cycle, I thought I would share them. These
- Microsoft Dynamics CRM – Application Lifecycle Management (ALM) – Session 1 – Shan McArthur – eXtremeCRM 2014
- Microsoft Dynamics CRM – Application Lifecycle Management (ALM) – Session 2 – Shan McArthur – eXtremeCRM 2014
- Microsoft Dynamics CRM Release Management Best Practices Revisited – Youtube video
- CRM Solution Lifecycle Management White Paper Summary
- CRM Solution – Release management best practices slide show
- CRM Solution Release Management Best Practices By Razwan for CRMUG 2016
- ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management
Deployment best practices
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
- ID on lookups
- early binding
- Unit tests
- never change production
- CRM Configuration mover
- Automate where possible
Automate your deployments
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
- Manual deployments are boring
- Manual deployments take a lot of time
- Manual deployments can go wrong due to use error
- it‘s a waste of developer
- More environments more time wasted
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
Benefits of the Solution Packager
The solution packager is a powerful tool which can automate importing solutions between environments but it has a number of other useful benefits.
Automated deployments
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
Track changes
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
Data
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
Solution Packager articles
Here is a collection of Solution packager articles if you want to learn more
- Create packages for the CRM Package Deployer
- Solution tools for team development
- MS CRM Solution Packager, why and how to use it correctly
- Tips and Tricks for Using the Solution Packager
- http://www.slideshare.net/ikurtev/tips-and-tricks-for-using-the-solution-packager
- https://waelhamze.com/2014/01/12/dynamics-crm-parallel-development-with-solution-packager/
- http://blog.stermon.com/articles/2016/02/09/ms-crm-solution-packager-why-and-how-to-correctly
- solution packager
- http://www.crmsoftwareblog.com/2013/07/crm-solution-packager-quick-look/
- Microsoft Dynamics CRM Release Management Best Practices, Revisited (Recorded Webcast)
- http://msdn.microsoft.com/en-us/library/dn688182.aspx
- https://community.dynamics.com/crm/b/tsgrdcrmblog/archive/2014/08/24/microsoft-dynamics-2013-sp1-package-deployer-tool.aspx
- http://kasperbirch.wordpress.com/2014/06/09/creating-deployment-packages-for-crm-2013/
Conclusion
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.
Hosk's Dynamic Blog 