I need a temporary workflow to update records in Production instance. I was thinking to just create one in production directly and run it on records and delete it. Whats the best way to do it, should I just create it in customization area (i.e. Default solution) and then delete it later or create a new solution, add this work flow to that solution and then delete that solution?
Or should I create it in Dev and then move the solution to Test/Production like we normally do?
As a best practice, create it in Dev using a new Hotfix solution - test it against some Dev records. Then export the solution (may be Managed one) & deploy in Test/UAT/Prod.
Once data fix is completed in Prod using our WF, delete the Managed solution (which will delete the WF too).
If you want - you can just deactivate the WF in Prod: Settings - Processes for future usage & to maintain environments in sync.
Never customize in the default solution - unless you're working on a managed solution (of which you have no control in Dev/Test), or are looking for a full list of components in an entity without adding them to your Solution (example - when writing a plugin, you need to know the field names of OOTB fields - I go to Default Solution to get these).
You didn't tell us in the message what your Workflow should be doing, and if it needs to be done in DEV or TEST.
What I would do is build the WF in DEV or test, re-create the situation that needs to be fixed in PROD, and test it in DEV/TEST. Once you know it will work, you can either push it over as a solution (or as a part of your existing solution), or, you can simply add it to your solution in PROD and then run it as required. If you need to delete it, great, delete it. If not, just de-activate it so people don't accidentally run it.
Related
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.
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.
There is a web app. Let's say I want to add a feature. I can write some code, test it locally, make sure it works - then publish it so it is available to the public. Some features though are very complex and not that easy to be written, tested and shipped the same way.
I want to make it so certain feature I am currently working on is not available to the public even though I publish the app.
Let's say I want to add a custom breadcrumb feature to the app (just for one page to keep it simple). I can write a block of code surrounded by some IsProductionReady variable maintained somewhere in Config file - then once I am done I can set IsProductionReady to True - so now it shows up.
I also want to be able to switch to any other features / changes and publish them without affecting any code, without showing any signs of Breadcrumb feature development. When I am done with the feature I want to be able to just make so it is available to the public.
What are the best practices or strategies to maintain a certain state of a feature? What is the best way to structure it?
If you're using Git, it's better to have a separate branch for each new feature, then after the branch being tested and approved you can merge them into your main develop branch, run another regression test (because different features may interfere each others functionality) and then move it to the Production branch.
Take a look into these urls, I presume you can find your desired scenarios in them :
http://nvie.com/posts/a-successful-git-branching-model/
http://martinfowler.com/bliki/FeatureBranch.html
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
I would have separate branches on Github between both and keep the structure the same. When your feature is ready, merge to the production branch.
I'm working on creating a deploy script to migrate new development from our dev server to our uat server. Unfortunately, the devs that made the changes didn't script them out at they coded. The easiest way for me to approach this is to use SqlDeveloper's database diff functionality. It does a good job of highlighting the differences and creating a script that I can run on UAT. However, I've noticed that it doesn't take into account any dependencies. For example, a it will put a command to create a table below a table that references it in a foreign key constraint. Because the referenced table doesn't exist yet, the first table create command fails. I've seen this with views referencing packages, packages referencing packages, etc. Is there any easy to way either 1) force sql to export in a "smarter" order or 2) manually calculate the dependencies (ex: querying USER_DEPENDENCIES, etc) so that i can manually sort the file of create commands without resorting to trial and error? I guess we could consider purchasing a commercial product as long as it matched exactly what we are looking for.
Note: we will probably have to deploy to UAT multiple times in order to support testing by end-users. I am trying to automate this as much as possible so I don't have to manually recreate this script every single time!
Thanks!
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.