We recently held a webinar on How to write code for SugarCloud. At the end, we gave a summary of some of the Dos and Don'ts for working with SugarCloud.
With more and more customers utilizing SugarCloud products, I thought it would be a good idea to expand on some of the basic best practices when developing for SugarCloud. As Sugar's cloud-based product line evolves, I will add more items to this list.
| When developing for SugarCloud: | |
|---|---|
| Don't | use custom code when configuration will do just fine. The ability to write custom code for Sugar is a huge benefit. It isn't, however, the best solution for all situations. Very often your problem can be alleviated by simply using the configuration tools that Sugar provides in its admin console. Manipulating a configuration in the system is typically a safer choice as there is no concern with upgrade compatibility. |
| Don't | have direct filesystem or DB access. SugarCloud is a shared environment. Any changes made to the filesystem could impact other customers. |
| Don't | use blacklisted classes, functions, or file types. In order to maintain the integrity of the standard Sugar functionality when we upgrade a customer instance and limit any negative impact our upgrade has on the customer's modifications, all instances hosted on Sugar's cloud service have package scanner enabled. Here is a blacklist of cases that will cause the package scanner to fail. |
| Don't | perform load or pen testing without permission of Sugar Support. SugarCloud is a shared environment. An unscheduled load test may cause performance issues with other customers' instances. You must obtain Sugar Support's permission so that they may make the proper adjustments to ensure no other instances are affected by your tests. |
| Don't | introduce performance or security issues with your code. For the safety and security of your users, it is never wise to introduce performance or security issues into your code. This is especially true when working in a shared environment so as not to affect other customers' user experiences. |
| Don't | disable or circumvent package scanner. Package scanner is enabled on all cloud instances to ensure no security violations are introduced. |
| Don't | allow an outbound HTTP connection to last longer than 1 second. SugarCloud is a shared environment. Long connections can have a performance impact on your users as well as the users of other customers. |
| Don't | abuse the job queue with a multitude of long running jobs. SugarCloud is a shared environment. Long running can have a performance impact on your users as well as the users of other customers. If you load the queue with too many long running jobs, the rest of the jobs awaiting their turn will be affected |
| Don't | abuse the REST API with more than 20 requests per second. SugarCloud is a shared environment. Too many requests can have a performance impact on your users as well as the users of other customers. |
| Do | upgrade to every new release. Sugar Sell and Sugar Serve operate on a quarterly update cycle while Sugar Market is updated approximately every two weeks. Each update will include new improvements or fixes from the previous version. It is important to keep up-to-date on these upgrades to minimize the number of things that will need to be tested. |
| Do | test before you deploy! It is always better to find any issues in a test environment prior to deploying live. If there are issues or incompatibilities after a change, these should be caught and addressed before a user runs into a problem. |
Want to learn more? Don't miss the webinar recording.