[sklett]

I’m attempting to learn the best way to work in a sandbox environment and move my changes back and forth from production and sandbox. Bundles seemed an obvious and elegant solution but I’ve already run into some problems. I couldn’t find a “best practices” for customizers using sandbox accounts.

In my first test this is what I did to get an existing object from production to sandbox and then back again. I hope there is a better way.[prod] Create bundle named “MyMiniProject – Prod>SB”
[sandbox] Install above bundle
[sandbox] customize, tweak, tune, etc
[sandbox] create bundle (including re-selecting all the objects to make it just like “MyMiniProject – Prod>SB”) and named it “MyMiniProject – Sb>Prod”
[prod] installed “MyMiniProject – Sb>Prod”
This works, but I have the following problems:Creating a second bundle to get the changes BACK to production is problematic. In my test I had a single saved search, but I could have just as easily had 10 forms, 4 scripts, some records, lists, searches, etc. Re-creating a duplicate bundle is just… well, it’s stupid, error prone and a waste of time. I hope I’m missing a better way?
I can’t delete the bundle on production. I created it to exchange data and changes, but I’d like to bake it into the account and remove the bundle, otherwise our account will get littered with “helper exchange bundles” as I move back and forth.
After typing that I thought “Well, I’m not sure how else they COULD handle this…” (that’s me calming down, BTW) I suppose a couple of functions would make most of the issues go away: Duplicate a bundle (and maintain a link so source bundle changes can propagate to shadow)
Ability to “bake” or commit a bundle to an account.

I realize that I could partition ALL my customizations into legitimate, logical bundles and leave them in place however that’s a seriously large task and not something I’d like to do.

How do you all move your work between accounts? I’m talking just scripts, that’s easy but objects. Am I doing it right? Any tips or tricks?

Deep breath….
This is a cached copy. Click here to see the original post.

[JMUnderwood]

RE: Using bundles for Production -> Sandbox (and back again)

Steve,

As you have discovered, bundles don’t work very well to copy from Prod to SB and back.

What would be a simple process between two databases seems very difficult with NS.

The best I have figured out is:Don’t install a bundle from Prod into SB
Either have NS create a new clone of Prod for a “clean” SB
Or start all development in the SB
It is still tricky to install multiple bundles from SB to Prod that have some common objects.If both Bundle 1 and Bundle 2 contain Object A, when you install Bundle 2 it wants to create a 2nd copy of Object A instead of using the one you installed form Bundle 1.
It’s been while since I did this, but I think now NS will give you an option of overwriting Object A on the 2nd Bundle

The best way to get started, as best I know, is to create a new SB (overwriting the old) from Prod, and then do all development in the SB.

HTH.

[elham]

As JMU points out, installing a bundle from production to sandbox doesn’t really make sense. The assumption is that people start their project in sandbox (presumably after a new refresh) so all the objects you need are already in sandbox.

We have had the option to replace existing objects in production using “Replace Existing Object” on the preview bundle install page.

Note that after you install a bundle from sandbox to production, then refresh the sandbox account, the definition of the bundle that originated from sandbox will be not be copied back to sandbox because sandbox will always be a complete copy of production. However, all the underlying objects that were installed into production from sandbox will be present.

As you say over time the production account may show many bundles installed but I don’t see why this is a problem. This is basically informational and includes metadata about the bundles that originated the underlying objects.

We are working on a deployment guide for sandbox to production workflows, similar to what we recently released called “Deploying Bundles” which is targeted mostly to ISVs (This is a good read for all SuiteBundler users).

Hope this helps.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

Originally posted by JMUnderwood

Steve,

As you have discovered, bundles don’t work very well to copy from Prod to SB and back.

What would be a simple process between two databases seems very difficult with NS.

The best I have figured out is:Don’t install a bundle from Prod into SB
Either have NS create a new clone of Prod for a “clean” SB
Or start all development in the SB
It is still tricky to install multiple bundles from SB to Prod that have some common objects.If both Bundle 1 and Bundle 2 contain Object A, when you install Bundle 2 it wants to create a 2nd copy of Object A instead of using the one you installed form Bundle 1.
It’s been while since I did this, but I think now NS will give you an option of overwriting Object A on the 2nd Bundle

The best way to get started, as best I know, is to create a new SB (overwriting the old) from Prod, and then do all development in the SB.

HTH.

Jim, I didn’t realize you had replied to this thread. I rely on the email alerts when someone replies and I got the one for Elham’s response but not yours.

I agree with your points, thanks for sharing. At this point I’ve got some issues with the Sandbox that I’m thinking will prevent me from renewing. I will spend almost the same effort to code and customize defensively in a Production account as I will working around the few sandbox/bundle snags.

Now, I’m sure some of you may be thinking “Oh come on Steve that’s BS. Sandbox, while massively overpriced, is a life saver and not that bad!”

Maybe for you, but for me the fact that all my permissions and saved search recipients are lost is a deal breaker.

I just did a test where I created a custom record and set some permissions for some roles. After installing it in Production the permissions are all gone!

This is useless for me.

Thanks again for the response Jim.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

Originally posted by elham

As JMU points out, installing a bundle from production to sandbox doesn’t really make sense. The assumption is that people start their project in sandbox (presumably after a new refresh) so all the objects you need are already in sandbox.

We have had the option to replace existing objects in production using “Replace Existing Object” on the preview bundle install page.

Note that after you install a bundle from sandbox to production, then refresh the sandbox account, the definition of the bundle that originated from sandbox will be not be copied back to sandbox because sandbox will always be a complete copy of production. However, all the underlying objects that were installed into production from sandbox will be present.

As you say over time the production account may show many bundles installed but I don’t see why this is a problem. This is basically informational and includes metadata about the bundles that originated the underlying objects.

We are working on a deployment guide for sandbox to production workflows, similar to what we recently released called “Deploying Bundles” which is targeted mostly to ISVs (This is a good read for all SuiteBundler users).

Hope this helps.

Hi Elham,

Thanks for the response and explanation of this issue. Unfortunately I find the sandbox and SuiteBundle useless for my needs. The fact that permissions to roles don’t translate is unacceptable and I don’t agree with the reasons. If you create a bundle that defines permissions for a role and the role isn’t in the target account then it should create the roles, not abandon all the security configuration.

I must be special in some way because I seem unable to make most NetSuite tools and features work for me. I really wish it was the other way around.

[William Bailey]

RE: Using bundles for Production -> Sandbox (and back again)

Saved search recipients not transferring is an oversite and will be corrected in 2010.1. Re perms between custom records and roles, did you make sure to include both the record and role in the bundle? If yes, then perms between the two should be preserved. If you included only one, then the perms are necessarily not bundled because one side of what they refer to is not there.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

The role used exists in the target account, additionally the bundler dependency resolver didn’t pick up that it was a custom role, it didn’t ask me to include it on the SB side.

[JMUnderwood]

RE: Using bundles for Production -> Sandbox (and back again)

Originally posted by William Bailey

Saved search recipients not transferring is an oversite and will be corrected in 2010.1. Re perms between custom records and roles, did you make sure to include both the record and role in the bundle? If yes, then perms between the two should be preserved. If you included only one, then the perms are necessarily not bundled because one side of what they refer to is not there.

William,

Thanks for the update. The fix you have planned for 2010.1 will help. It would be more helpful if it was released sooner.

When I first started customizing NetSuite years ago as a NS customer, one of the first major shortcomings I discovered was the lack of support for a true development environment. NS eventually partially addressed this with SuiteBundles.

While I have a more detailed post in the Best Practices section, allow me to highlight the primary needs of any developer in any software/database application:We need 3 versions of the system to work with:Production — for use by end-users in actually conducting their business
Development — for use by the development team ONLY to make changes and enhancements to the software and DB
Test — for use by development integration team and the end-user testing/acceptance team
When working with traditional software and database systems the developer has full access to all of the version control and database tools that make it very easy to copy/move software, data structures, and data from one Version to another.

While SuiteBundles are a very welcome tool, and have significantly enhanced our ability to customize NetSuite using professional best practices, it still falls significantly short of the above.

NetSuite has driven the design of SuiteBundles primarily to support third-party developers who can make add-ons for NetSuite. This certainly has it benefits, and would be even more beneficial if NS would release more bundles that address common needs.

Having said all that, it would be most appreciated by NS customers like Steve if NS would further enhance SuiteBundles, or add other tools, to make it easier internal developers.

Just my 2c.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

Originally posted by JMUnderwood

Just my 2c.

That’s some good $0.02, you’ve got it perfect.

[William Bailey]

RE: Using bundles for Production -> Sandbox (and back again)

Steve, say you bundle a saved search that operates over a custom record. The bundler will auto-pull the CR out of necessity – the search has no meaning without the CR it is defined to operate on.

The general rule is auto-pull is only performed out of necessity. For CRs and roles, they can live independently. So just because a CR references a role doesn’t mean bundling the CR will auto-pull the role. But if you simply bundle both, all data relating between the two will be preserved.

Because you are installing from sandbox to prod, the preview page will notice the CR and role already exist in the target account and give you the option to add new copies, or replace the existing.

I believe the “auto-pull” idea is covered pretty well in the various suitebundler help pages and doc.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

Originally posted by William Bailey

Re perms between custom records and roles, did you make sure to include both the record and role in the bundle? If yes, then perms between the two should be preserved. If you included only one, then the perms are necessarily not bundled because one side of what they refer to is not there.

William,

This results in the Target Role being mangled and losing all the Custom Record permissions except those directly related to the record being imported.Created a custom record in SB
Added some permissions for some roles that exist in SB and Prod
Manually added the roles when creating the bundle on the SB side
Installed the bundle on the production side
Chose the replace option for the roles
All the custom record permissions for the roles are deleted except the ones that apply to the custom record included in the bundle.

Oops.

[sklett]

RE: Using bundles for Production -> Sandbox (and back again)

Actually I think this is even more strange. Field level permissions seem to be cleared out but custom record permissions are retained.

Just a mini update for others that may find this post.

[Author]

Posts