Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Two developers configuring in the same environment - Best Practices

  • 1.  Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 19 days ago
    We have a team of two people working together in the same environment. The goal is to do everything OOB (minimum coding if there's no workaround) and I want to be able to see the configurations per developer, so if they would be working in two separate unmanaged solutions, I would have the work marked by Publisher. But then how do I merge two unmanaged solutions? I don't think that is possible, so maybe unmanaged solution for one and a Solution Patch for the second developer?...
    The same way with two Patches into one unmanaged solution, but patches get merged and I will loose the publisher...or not?
    What is the best way to work on configuring D365 CE with two developers?
    I want to mention that my above comments refer to Dev Sandbox.
    Then we would export in a managed solution for testing (or is it better unmanaged?) and finally export to managed for Production.

     I am looking to see what would be the best collaboration strategy in each case:

    1.  The two internal devs working together (no third party)
    2. One internal dev working with a Partner



    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------
    CRMUG Summit - Post


  • 2.  RE: Two developers configuring in the same environment - Best Practices

    Posted 18 days ago
    Hi Emilia

    It's definitely possible to merge two unmanaged solutions together - the issues come when they're managed!
    You can add all of the components from one unmanaged solution to another unmanaged, in order to create a single solution.

    ------------------------------
    EY Kalman
    Senior Manager
    PwC
    ------------------------------

    CRMUG Summit - Post


  • 3.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 18 days ago
    Thank you, so I've heard :).

    I have been doing some research and testing and here is what I have found:
    • have unmanaged Main solution with organization Publisher and bring in all existent components reequired for the first "sprint"
    • create patches for each developer (individual Publishers) and have them work in patches 
    • after dev testing, clone the solution (it will keep the devs publishers in the newly created components and the changes in forms and views will be given by the tool with Visual Studio)
    And here is where:
    1.  I would export managed for the Test environment?...
    2. Get feedback then make any changes back in the Dev environment (using patches)?...
    3. Then export again a managed sol from Dev in the Test environment?....
    4. Once UAT done, I export managed into Production?.....
    If a change is required to production later on, I go to Dev create a Patch and so on...

    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------

    CRMUG Summit - Post


  • 4.  RE: Two developers configuring in the same environment - Best Practices

    SILVER CONTRIBUTOR
    Posted 18 days ago
    Emilia,

    My take is that managed solutions are for third parties to deliver solutions to customers.  Keep in mind that if you remove a manages solutions all the objects in the solution are removed including any underlying data in the entities and attributes in the solution.

    It may be better to consider the objects that are being maintained by a developer.  If possible have them work on different objects in their own solutions.  Once their updates are ready for testing they can be added to a main solution, if needed.

    The only large project I worked on had around a dozen developers and QA people.  We all had our own instance of CRM on local VM images.  We would then export and import our work into a central development environment that was then reviewed by the business analysts then moved onto a test environment for the QA people to validate.  This approach seemed to work well since the developers didn't get in each others way most of the time.

    Hope this helps.

    Wayne.


    ------------------------------
    Wayne Wittman
    CRM Administrator
    MiTek Industries Inc.
    Clifton NJ
    ------------------------------

    CRMUG Summit - Post


  • 5.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 18 days ago
    A very good recommendation if our project will get larger in a future phase, thank you, I took note. (I am sure Integration with the ERP system for example will need a such strategy)

    For now our project is not that large - customer service and field service for small to medium organization -  (at least this first phase :) so working in the same environment will be fine. I just want to double check the strategy of using unmanaged solution in Dev and using managed solution in Test environment Production. I have been hearing and reading horror stories about managed but Microsoft is guiding us to use managed....

    So what are advantages and disadvantages in:
    1. using same environment working with 2 unmanaged solutions (two developers/configurators) merged into one solution  versus
    2. using same environment one unmanaged solution, but working with 2 patches(2 Developers/configurators) to be cloned into the one solution?​
    and Dev - unmanaged, Test - managed and Production - managed.

    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------

    CRMUG Summit - Post


  • 6.  RE: Two developers configuring in the same environment - Best Practices

    SILVER CONTRIBUTOR
    Posted 17 days ago
    Emilia,

    I may be missing something but if the customization are all internal I don't understand why you would want to use a managed solution.  From my reading hear some people keep the solutions in the database forever.  I don't.  Once I know the customizations are stable I archive the zip file and remove the solution from the CRM organization.

    Keep in mind that if you are modifying the same object such as a case form or account JavaScript web resource the 'old' solutions are of no value keeping in the database since the object gets overwritten anyway with the the import of the new unmanaged solution.

    Wayne.

    ------------------------------
    Wayne Wittman
    CRM Administrator
    MiTek Industries Inc.
    Clifton NJ
    ------------------------------

    CRMUG Summit - Post


  • 7.  RE: Two developers configuring in the same environment - Best Practices

    SILVER CONTRIBUTOR
    Posted 18 days ago
    Hi Wayne, how did you used to sync the environment in the VMs with dev environment?

    ------------------------------
    Hasan Bazerbashi
    Programmer Analyst
    Cineplex Inc.
    Toronto ON
    ------------------------------

    CRMUG Summit - Post


  • 8.  RE: Two developers configuring in the same environment - Best Practices

    Posted 17 days ago
    Hi,

    Microsoft published a document 'Solution Lifecycle Management: Dynamics 365 for Customer Engagement apps'.

    It provide guidelines that you may want to follow to stick to current and future solutions management 'philosophy'.

    Notably, there is a chapter 'Common Implementation Pitfalls' / 'Developing multiple solutions in a single development instance' that match your current setup.

    You can download it here:
    https://www.microsoft.com/en-us/download/details.aspx?id=57777

    Have a good read!


    ------------------------------
    Fabien Bernard
    CRM Developer
    Montréal QC
    ------------------------------

    CRMUG Summit - Post


  • 9.  RE: Two developers configuring in the same environment - Best Practices

    SILVER CONTRIBUTOR
    Posted 14 days ago
    Emilia,

    I would recommend not using different publishers. I have seen it used with the same purpose you are mentioning, and the first iteration everything might be fine. Problems can arise though when you later on want to update solution objects, and you may see situations where an object cannot be updated in test/prod since it is owned by another publisher.
    And then the issues mentioned by Fabien, of course.
    But it seems like you have a solid ALM going, so I think you are over complicating things when going for the different publishers :)
    Using different solutions and finally merging those should not really be a problem, although perhaps unnecessary if your devs check in their deltas properly.

    ------------------------------
    Jonas Rapp
    MVP, Enterprise Architect
    Sweden
    ------------------------------

    CRMUG Summit - Post


  • 10.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 14 days ago
    Thank you all for your feedback!!!

    I will not take a chance to run into complications later, so I will go back to one publisher.
    I read your advices, Microsoft's documentation and I am glad I'm on the right path :).
    Thank you.

    Regards,

    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------

    CRMUG Summit - Post


  • 11.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 17 days ago
    The XrmToolBox has a Solution Components Mover plugin that you can use to add all (or some) of the components from one unmanaged solution to another unmanaged solution.  Works Great!  Also I would recommend having a single publisher for your changes.  Not sure what it buys you having two developers each with their own publisher.

    ------------------------------
    Daryl LaBar
    President, MVP
    Gap Integrity
    Fishers IN
    ------------------------------

    CRMUG Summit - Post


  • 12.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 17 days ago
    We are working in Dev Unmanaged, then export Managed into Test, Production.

    The idea with the unmanaged patches in Dev, came from the fact that we have two people working internally on it and its easy to identify at a quick glance (if they have different publishers) what one created versus the other one. We do use the Version Control also, but this is a quick reference for us.

    Once patches are tested, we merge them to the Main Solution and then export Main Solution as Managed into Test.

    I will look into the Solution Components Mover for the alternative of using two unmanaged Solutions and future reference, thank you.

    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------

    CRMUG Summit - Post


  • 13.  RE: Two developers configuring in the same environment - Best Practices

    Posted 17 days ago
    I now understand that more than the publisher, you are using the entity logical name prefix to distinguish which of your 2 developers have  created the entity or the fields.

    I see some drawbacks to use this convention:

    • if dev1 & dev2 do add values to same option sets, values could at best not be continuous, at worst collide.
    • Some tools (e.g. CRM Rest builder), some places in CRM or some third party software use only entity logical name when entity list is presented. You will then have to know who created the entity in order to quickly find the entity you are searching for.
    • This applies also to fields inside an entity.

    These are just some thoughts I wanted to share, maybe your requirement to know who created components is critical.

    The way you are using solutions seems solid though, I would just have used the same publisher. In my opinion, database entities and fields creation should be documented regarding a business requirement and not be bound to a specific developer.

    ------------------------------
    Fabien Bernard
    CRM Developer
    Montréal QC
    ------------------------------

    CRMUG Summit - Post


  • 14.  RE: Two developers configuring in the same environment - Best Practices

    GOLD CONTRIBUTOR
    Posted 14 days ago
    Thank you all for your feedback!!!

    I will not take a chance to run into complications later, so I will go back to one publisher.
    I read your advices, Microsoft's documentation and I am glad I'm on the right path :).
    Thank you.

    Regards,

    ------------------------------
    Emilia Scott
    Data Architect
    ------------------------------

    CRMUG Summit - Post


  • 15.  RE: Two developers configuring in the same environment - Best Practices

    Posted 13 days ago

    Hello Emilia,

    It's a good thing you chose to keep one publisher. Solution Components Mover proposed by Daryl will help you a lot in your case and it is such easy to use.

    You said you already have version control for your solutions. Are you using Azure DevOps Server (previously named TFS)? In that case, Dynamics 365 Build Tools can help a lot in automating your process. For example you could have this process when a developer want to push it's changes to the main solution  :

    - copy solutions components in main solution
    - export main solution and extract it in a new git branch
    - create a pull request

    Then you could easily check their changes in the pull request. and keep track of changes history.

    Good job of taking care of ALM best practices in your environments!

    Best Regards,



    ------------------------------
    Laurent Maneville
    N Media
    Drummondville QC
    ------------------------------

    CRMUG Summit - Post


  • 16.  RE: Two developers configuring in the same environment - Best Practices

    Posted 13 days ago
    Good point Laurent,

    Using SolutionPackager tool, both developer can work using the same solution, merges are done through the source control.

    This is now officially documented here:
    https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/use-source-control-solution-files


    ------------------------------
    Fabien Bernard
    CRM Developer
    Montréal QC
    ------------------------------

    CRMUG Summit - Post


  • 17.  RE: Two developers configuring in the same environment - Best Practices

    Posted 12 days ago
    Well, I manage a team of four developers plus myself and here's how we do it.
    First we keep track of everything we're building as Jira stories.  We make sure people are assigned to things that make sense together. For example, one person might take on all the javascript on the Opportunity form, another person may be working on workflow optimization.  Another person is working on a particular plugin, etc.

    Everyone uses one solution - we create one solution per "release".  In the first section where you can put notes, we all put in what we added to the solution, in shorthand. For example, I might write "added Opp entity to update main form for ticket 324".  Or sometimes just the ticket number.
    We meet every week to discuss what we're working on, challenges, any questions or interactions we have for each other.

    Right before we migrate to QA, we meet to go through the whole solution, cross-checked against our list of items from Jira, make sure we got everything in the release, nothing was not in the solution, and that we don't see anything in the solution that shouldn't be there.

    It works really well but it does take management and everyone has to agree to standards.  For example, we have a standard that any workflow we disable is renamed "DNU" and goes into the solution so it can be disabled in all environments.  Or we have a standard that any updates to workflows get an update in the Description as a sort of change log.  For javascript, we have standards around commenting.

    ------------------------------
    Shannon Davis
    eBusiness Program Manager and Business Analyst
    Analog Devices
    Norwood MA
    ------------------------------

    CRMUG Summit - Post


  • 18.  RE: Two developers configuring in the same environment - Best Practices

    Posted 11 days ago
    Thanks Shannon for sharing your methods which would certainly give some ideas to others.
    Having standards is the key when several people are involved.

    One question though: how would you handle this scenario:
    Let's say one of the functionality deployed in the solution bundle introduced an unexpected behavior that was not catch during QA. Or this functionality is suddenly not required anymore by the business and they want to step back?

    It is never easy to 'undo' a functionality that has been merged into one solution and this can cost a lot of time to do this manually.
    I believe having solutions under source control using SolutionPackager (having a branch per functionality) would allow to remove one functionality without too much effort. It would also enable, be able to fix a production issue without disrupting current developments, having a larger development while not blocking smaller development deployments, having a side proof of concepts branch ...
    This is also a required step to setup ALM / devops which open the doors to automated deployment and automated testing, which can save a huge amount of time down the road.

    Personally I always worked like you do with standards, but I aim to follow Microsoft recommendations and setup a full ALM / Devops processes.

    Having feedback from users that achieved this would be appreciated. Does it worth the effort to set those processes up? Even for a small team with few developers?


    ------------------------------
    Fabien Bernard
    CRM Developer
    Montréal QC
    ------------------------------

    CRMUG Summit - Post


  • 19.  RE: Two developers configuring in the same environment - Best Practices

    Posted 11 days ago
    Edited by Laurent Maneville 11 days ago

    "Does it worth the effort to set those processes up? Even for a small team with few developers?"

    Having a perfect ALM process can take a lot of time for small teams so not always worth it.

    Yet little things can be easily set up. And i would say that using version control is a must have even for small projects.
    Using Clone a patch for exemple is an easy builtin way to have a separate solution for each change.
    Before a release, just use Clone Solution, then export solution, extract code and but it in Git

    This can be done manually at first then easily automated



    ------------------------------
    Laurent Maneville
    N Media
    Drummondville QC
    ------------------------------

    CRMUG Summit - Post


If you've found this thread useful, dive deeper into User Group community content by role