Apex Code Development You need to sign in to do that
Don't have an account?
vr8ce Repeatable object creation?
Point-and-click is great until its time to do something repeatable. This is less of a "how to" question (although "how to" answers are welcome) and more of a "best practices" question.
We need to create a few new custom objects. We can do it in a sandbox, but the instant we refresh the sandbox the custom objects are gone, and we would have to create them again. Further, if we determine after creating them that we need to add another field or three, then we have to keep track of the fields for the next time we have to create them. It seems like 1) a lot of wasted time, and 2) errors waiting to happen.
In another world, e.g. SQL Server, we would script the object creation. But in that world, creeating the script is easy (no objects), and running the script is easier (SSMS).
What is the recommended method for Salesforce, and/or the generally accepted method? Do people generally just repeat the point-and-click every time, or do they create Apex scripts? (I would think the percentage of orgs who can do the latter is pretty small.)
I've done some web searches on this, but have not stumbled across the right combination of terms or something, because I have found almost no posts with any real information.
We need to create a few new custom objects. We can do it in a sandbox, but the instant we refresh the sandbox the custom objects are gone, and we would have to create them again. Further, if we determine after creating them that we need to add another field or three, then we have to keep track of the fields for the next time we have to create them. It seems like 1) a lot of wasted time, and 2) errors waiting to happen.
In another world, e.g. SQL Server, we would script the object creation. But in that world, creeating the script is easy (no objects), and running the script is easier (SSMS).
What is the recommended method for Salesforce, and/or the generally accepted method? Do people generally just repeat the point-and-click every time, or do they create Apex scripts? (I would think the percentage of orgs who can do the latter is pretty small.)
I've done some web searches on this, but have not stumbled across the right combination of terms or something, because I have found almost no posts with any real information.
A quesiton springs to mind - Why the need to recreate the custom objects after refresh?
Generally on a Sandbox refresh, you derive the structure from another instance. So if the custom objects exist in production, then they appear in the refreshed sandbox. Note: when refreshing a sandbox, you can also refresh from other 'connected' Sandboxes. Check 'Deployment Settings' to set up the connections.
In line with the above, perhaps create a Sandbox called "Template". It contains the extra custom objects you require. Refresh from there. And when you add new fields, do it in the 'template' sandbox and then either refresh the other sandbox, or do a changeset.
Aspects that I have heard of but not tried:
Unmanaged packages - have components ready to deploy as package
Post copy Apex classes - however, all posts i have seen here relate to manipulating data, not creating meta-data.
Regards
Andrew
I want to develop in the sandbox, but I still need to be able to refresh the sandbox from production. That means whatever objects I've created I need to be able to re-created.
Devlopment env (where you do dev)
Testing env (where your users do testing)
Production (where the real work happens)
So, you build something in Dev (project1) and push to Testing. Whilst the users are testing, you want to keep developing, so need a new env to work with whilst testing happens. Therefore created Dev2 from Prod and start project 2 in there.
Halfway through development for project 2, the testers say 'we are done, make it live'
You push a changeset from Testing to Production. So production is now updated ( Prod plus Project 1 ).
You want to ensure that Project 2 environment shows Project 1 changes.
Options:
1. Use the changeset that pushed from Testing to Prod - set a connection from Testng to Dev2 and push the change set.
or
2. Create Dev3 from Production, bundle up existing changes in Dev2 into changeset and push to Dev3.
or
(least favourable from a productivity aspect) don't do any new development until project 1 is live and then refresh the changes back through testing and Dev1.
If the environments you are working with are more complex than the simple representation above, then you may need to chase down the CICD path using Scripting, Ant, Code repositories and other such features.
Regards
Andrew