Solution Design

(0) Share

Report

Posted on by Schalky

Hello

Just curios to get people's opinions on how they design their solutions for deployment.

I have come to a new company where they have simply created one Base solution a have deployed it as unmanaged solution across all environments including production. (this is an enterprise environment). They deploy this solution for every change regardless of what the change is.

Is is this standard practice for anyone?

I have come a custom with creating smaller solutions separating the business functions and deploying these as managed solutions.

Just wondering whats people thoughts are on this and if you have any better solution designs.

Thanks,

*This post is locked for comments

I have the same question (0)

All responses (8)

Answers (0)

Suggested answer

Community Member on at

Like (1)

Report

I believe the approach you are using is a good one. You just need to shift the changes you have made recently. However, using managed and unmanaged solutions depends upon your requirement. The managed solution can be uninstalled if there is an issue. Personally, for production instances, I prefer using managed solutions.

Was this reply helpful? Yes No
Suggested answer

ScottDurow 21 on at

Like (4)

Report

If you are deploying to envrionments that you are in control of then I recommend using unmanaged solutions - if you are more like an ISV where you are deploying to envionrment that you have no control of what customisations are applied after you install then use Managed solutions.

There are so many more complex scenarios you need to understand to use Managed solutions that you need to be sure of the benefits you are getting from using them.

Was this reply helpful? Yes No
ScottDurow 21 on at

Like (0)

Report

How are you getting on - do you need any more help?

Was this reply helpful? Yes No
Schalky 30 on at

Like (0)

Report

Thanks for your input, there are indeed a few variables to consider. One issue is that when deploying the unmanaged solution it tends to make the crm site not accessible . Likely due to Server Resourcing ( I am not able to check this as i don't have access to the servers.) This is what i have been told by the admins. This is a big part of my reason to change to smaller solutions as my understanding of deploying the solutions is that while it may slow the system and put locks on the database it should still be accessible. The business is striving for a more agile environment but seems a bit hindered with the current method of deployment.

Was this reply helpful? Yes No
tpeschat 4,930 on at

Like (0)

Report

I create unmanaged solutions for each release containing only the components I added or changed.

Br Thomas

Was this reply helpful? Yes No
Suggested answer

AMREEK SINGH 710 on at

Like (0)

Report

I am working with government departments for last 7 years. I will not deploy an unmanaged solution to any environment except dev. We always deploy solution after hours. What would you do if you find out 10 hours after the deployment that the new solution has caused some major issues? You can't restore the database as it will delete all the records created in last 10 hours. Now you have to manually remove all the changes. Depending on the changes you made, it may take you hours to undo those changes. Managed solutions can be deployed side by side and you uninstall the latest solution to revert the changes. It will also stop the deployment teams or administrators to make unwanted changes to solutions in test, UAT and production environments.

As a best practice, I will stick to deploying managed solutions to test, UAT and production environment.

Regards,

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (1)

Report
Case 1) you are ISV - Use managed (Piggybacking on Scott’s Suggestion)

Case 2)

(you have Corporate Environment or want more control on changes ) &&

(Your development Environment does not contain any 3^rd party managed solution) &&

(You have a plan to keep your Development forever without decommissioning ) &&

(there is no future plan to do instance Copy of your Production CRM to Development)

Then - use managed

Case 3) ALL the rest use unmanaged

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

For me a solution is the set of changes that provide the solution to a set of business requirements. So each deployment / sprint / phase should ideally be in a Solution file which contains only the things that have changed. This has been much easier to achieve in practice with the more granular level of control of which assets are included in a solution in the first place (eg just the exact fields, forms or views that have changed, rather than a whole copy of an entity).

Variation of that idea: Each bit of development (eg backlog item) is in a separate solution and this is deployed unmanaged from Dev to UAT / staging / test / whatever you call this. Then your "super solution" in that environment contains all items that have ever changed since the base installation, and you deploy this from UAT to live / production. Again, unmanaged.

Like others on the thread, for me unmanaged is always the right option for internal development, including any bespoke customisation done by a partner or consultant as a "work for hire" on behalf of a client. In this situation you are just acting as an extension of the client's own skills and resources. Unless your contract says that you own the IP in the work you are delivering, it belongs to the customer who is paying for it.

Managed solutions should be used when you are distributing the same changes to multiple different environments belonging to different people. This means ISVs, or perhaps VARs using components they have built for previous projects and find useful to re-use as part of their "value added" proposition. Reasons for using managed solutions in this way include:

- you own the IP. All of it. And need to assert your rights to it.

- you charge for using the solution on an ongoing basis. If the customer wants to stop using it they can stop paying, and uninstall (that at least is the theory of how managed solutions work...)

- needs might change, and the customer wants to remove your solution. As an example, a client of mine is using a solution their original partner installed as part of the overall deal, there is no ongoing licence to use it. But it is really badly designed and they want to remove it and build their own better approach instead. Rather than unpick the pieces, they can simply uninstall. But this was NOT part of the "work for hire", it was an off-the-shelf component the VAR used on many/all projects.

- you need to be able to lock down some aspects to protect against changes in order to ensure the customer does not break the solution, especially if you have to provide ongoing support for it

Was this reply helpful? Yes No