We are actually reorganizing our CRM customizations. Till now we had one main solution which was containing all the customizations and now we would like to split it by technical matters.
So now on our development instance, we have 4 unmanaged solutions that we would like to publish on tests instance which has the old managed solution.
We plan to do the following:
-> Export the 4 solutions to managed
-> Import them to test instance
-> Uninstall the old solution from test instance
I have a doubt concerning that procedure. Will it break something?
At some point we'll have the same customizations from different solutions. What do you think ?
I tested your steps on a trial environment with a couple Solutions and although when I began I believed (as Arun answered) that uninstalling a managed solution would delete all objects regardless of usage by other solutions, when I actually tested it, it's not deleting them. Data was also kept.
So the steps:
-> Export the 4 solutions to managed
-> Import them to test instance
-> Uninstall the old solution from test instance
Might work with no issues.
I would recommend that you make sure to checklist all elements so nothing is left behind.
If you have an available instance I would also say that you first restore a backup and test that everything goes as planned, but from my test it worked out.
I'm also curious about this exercise. If this is another sandbox to play-around by only disrupting the QA team (without any concern to Prod instance) - I will go with the listed steps to see if it goes through. We can wipe out this Test Org with the Restore from Prod anytime later if it didn't go through all the way.
Or else spin a new sandbox copy of exact Test replica for dry run.
At some point we'll have the same customizations from different solutions.
True, but uninstalling the existing Managed solution will remove the components though they are part of another Managed solution, if I'm not wrong.
This is a common approach. We also have split our customizations into several solutions. (e.g. one for Plugins, Security Roles, Web Ressources...)
You can split your customization work into as many solutions as you like, but don't overdo it.
Related
We are a Housing Association. We use CRM 2016 SP1. Our Dev and QA environments are single server configuration and staging and production are multiple server config with load balancers. Our custom solutions in QA, staging and production are managed.
We needed to update a "Quick Find Active" view for two of our entities Person and Property with some extra search columns in our staging and production environments.
I added the new columns to those entities' views in Dev environment by going to Settings->Solutions->[custom solution]->Entities->[custom entity]->Views->Quick Find Active [entity]->Add Find Columns. I did the same for both entities.
To deploy the update to other environments as a patch, I exported a standalone solution file that only contained the Person and Property entities with the updated views. I then imported the solution file into the QA environment to test.
Having published the changes in QA after import, I checked the entities' Quick Find Active views in the default solution (Settings->Customization->Customize the system->[custom solution]->Entities->[custom entity]->Views). I noticed that the Property entity was updated with the changes but the Person entity was not. It made no sense.
Having spent some time to search the Internet for an answer to no avail, we decided to try out the patch solution in staging. So we exported the solution file but before publishing the changes we decided to check the update. To our surprise, both entities had been updated. So we did not publish the changes.
Happy with the result and blaming the problem on our QA environment, we decided to go ahead with the deployment to production. We imported the file and check the changes and noticed that this time around the opposite happened to our entities, i.e. The Person entity had been updated but the Property entity had not!
We tried publishing the changes but it made no difference. So at the end we gave up and had to complete the deployment by manually updating the views in production.
I am wondering if anyone else has experienced this oddity. Any help/suggestion is greatly appreciated.
You mention that you are deploying managed solutions, and that your changes are not taking effect. The entities contained in the solution have previously been deployed to the target environments.
If you have previously made any modifications directly to the target environment (which would not seem improbable given that you did so this time), these changes will be in the unmanaged layer, which by default overrides changes in managed solutions:
MSDN says:
Because unmanaged customizations are considered ”above” any managed
solution in terms of conflict resolution, organizations installing an
update to a managed solution may not see their changes applied because
of unmanaged modifications. An option exists to make sure that changes
applied by an update to a managed solution are available.
When you
release an update to a managed solution, the organization installing
the update can select:
To preserve any customizations it has applied on top of your managed solution.
To overwrite any customizations it
has applied on top of your managed solution.
In conclusion: Never make any modifications directly to your target environments if you are using managed solutions. It will cause you issues later.
Thanks to Henrik who replied to my question and put me in the right direction. We managed to resolve this issue. Refer to this page to read the solution.
Can you explain to me what it means :
An unmanaged Solution can be published as a managed Solution
Thanks in advance,
Publish is a slightly misleading word to use. What you in fact do in dynamics is Export a solution.
With that said, when you export a solution (as a zip file) you have 2 options during the export process. This is what they are and what each mean:
Unmanaged
When you import this into the target all components included in the solution are installed/overwritten. All of the components are editable on the target environment and fully customisable.
Deleting the solution will not remove any of those components, it just removes the solution reference leaving everything still installed. Think of it like an open box. You empty the contents onto the target, but removing the box simply... removes the box.
In theory this sounds like the worse option, but in a standard release process it's actually more favoured amongst the seasoned developers (that I have worked with anyway).
Managed
Is more of a closed box or a package. All the contents are installed and potentially overwritten (you can choose to maintain customisations, but I'm not sold on this feature yet, it's never proven useful to me).
Using managed solutions gives you control over the "customisability" in the target environment. You can choose to completely lock down a component (effectively make it read-only) or you can allow it to be customised.
Deleting the managed solution completely removes all components from the target server (including data in the entities). Hence why I call it a closed box/package. Although, to be honest, I have never successfully managed to delete a larger solution from an environment so not sold on this feature consistently working.
Managed solutions are usually best saved for "products" or "addons".
Also worth noting, you cannot export a solution which was originally imported as a managed solution into that environment.
For Dynamics CRM 2011, Microsoft suggests moving entity customizations from DEV to PRD by packaging the changes as managed (or unmanaged) solutions. Unmanaged is bad because you cannot remove the entities when you need to (deleting the solution only deletes the container, entities contained in the solution remain). In most lab examples during training, you’d customize the system, then export the customized entity as a managed solution, then import it into production. This solution-based approach is clean, makes it easier to control what’s in PRD, bundle related entities together, track dependencies, etc, so I get that.
There are times, however, when you need to dump the org on the DEV server and restore from PRD (to address a data-specific issue or for other reasons). We do that by disabling, then deleting the DEV org, then asking the DBA team to restore the CRM database from production, then we import the org back to the DEV server. But if we implement this “managed solutions”-based change migration process, won’t we lose the ability to change our entities after we dump DEV and recreate it from PRD, where these solutions are sitting in read-only mode? If we enable customizations in these managed solutions, will we be able to add new entities to the solutions or remove entities from inside the solutions without deleting the entire solution? Because I thought managed solutions are treated as a single unit of code, so it’s either delete all or delete none. Interested in learning how others have resolved this issue.
One way we have handled this is using a seperate clean dev machine which we use to manage the configurations as the "configuration master". That machine is not used for any other dev or test work. The dev machines for plugsin, etc. can be rebuilt from prod, but this machine continues to be the master for all solutions. Not an ideal solution, but it does avoid the "feature gap" of being able to convert managed solutions to unmanaged (maybe through some password facility)
I would advise against using solutions in these type of dev-to-testing-to-prod situation.
If you are unsure about this try to remove an entity in your dev environment and publish the change to your production environment.
Solutions are inclusive meaning that CRM doesnt remove fields and entities that where deleted in your solution.
The only way to remove an entity is to uninstall your solution therefore deleting the production data in all entities covered by your solution!
While in theory solutions seem perfect they are only usefull for third party vendors.
The goal of beeing able to rollback by uninstalling your solution is a pipe dream. Consider a data model update that involves data conversion. No magic function will reverse that.
It is a far simpler and reliable to restore your backup.
Sorry if a similar question has been posed before. There are a lot of deployment questions but none seemed to address my problem.
Anyway. I'm working with asp.net, C# and using Visual Studio.
The Organization I'm working in is changing rapidly. There are a lot of projects coming in the pipeline that will require multiple code changes and iterative deployments over the next few months. While working, these changes are always 'on the forefront', so sometimes I have to code certain parts of the same program multiple times.
Since these projects are all staggered, I can't just make one sweeping change all at once; I have to deploy and redeploy the same program multiple times, using only the changes that are required for that deployment.
If this is confusing, here's a simple example:
Application is being used on an Intranet. This application calls our Database, using Driver A.
There are two environments, test and production.
Certain Stored procedures have to be called with parameters that register 'Test' to allow certain other applications to run even with bad data (for testing purposes).
When deploying applications, these stored procedures have to be modified, removing Test parameters
We have an Operating System upgrade, allowing us to move to a much faster Driver B, but requires changes to be made to the code to use Driver B.
So that's two wholly different deployments where some code must be changed for Deployment 1 and other code must be changed for Deployment 2.
Currently I'm just using notepad for an overall change list, regular debugging break points and a multitude of in-code comments, and then I manually slog through the code to make sure that everything is changed. With hundreds of thousands of lines of code over multiple files, classes, objects, etc. this gets pretty tedious, as well as there being a good chance of missing something (causing it to break) or pushing wrong changes (causing it to either break or allow bad data).
Is there a tool that could be used to help in this situation? Preferably one that I can discern what needs to change for Deployment A and what needs to change for Deployment B? I'm also open to hearing other schools of thought as well (tips are definitely accepted!)
Sure, I understand your problem.
I would suggest a couple of things
Installers : Why don't you think of installers, there are loads of installers i.e Install shield, Wix, MSI installer.
These installers will give you flexibilty to update files which you need to update, i.e. Full Control.
But you need to choose the best of them, I have worked around MSI and Wix a lot, so I know this can sort your problem, however its your call.
Publish : I haven't played around much with this, I have just done website publish. However I know it does wonders, so try it also.
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.