SuiteApp Development Process with SuiteBundler

Note:

SuiteBundler is still supported, but it will not be updated with any new features.

To take advantage of new features for packaging and distributing customizations, you can use the Copy to Account and SuiteCloud Development (SDF) features instead of SuiteBundler.

Copy to Account is an administrator tool that you can use to copy custom objects between your accounts. The tool can copy one custom object at a time, including dependencies and data. For more information, see Copy to Account Overview.

SuiteCloud Development Framework is a development framework that you can use to create SuiteApps from an integrated development environment (IDE) on your local computer. For more information, see SuiteCloud Development Framework Overview.

The SuiteBundler feature offers flexibility in how you distribute bundles to other NetSuite accounts. Whether you are an internal developer creating customizations for your company, an independent software developer (ISV) distributing solutions to your customers, or an administrator who wants to make a bundle available to other users at your company, NetSuite provides different methods for you to use.

At the core of this SuiteApp development process is the development account. A NetSuite development account is an account, isolated from production, in which you can develop and test new applications and customizations without worrying about affecting your production account. Each development account has the same features and modules as a production account, but it does not contain production data. For more information about development accounts, see NetSuite Development Accounts.

You can use separate development accounts for developing, testing, and releasing customizations. Use SuiteBundler in conjunction with the customizations created in a development account to package the SuiteApp as a bundle for distribution.

Support for bundle operations varies across the different types of NetSuite accounts, including development accounts. See Bundle Support Across Account Types.

Important:

This section contains best practices for managing SuiteApp development with development accounts in conjunction with sandbox accounts. These best practices are recommended by NetSuite. You can, however, adapt the best practices to your own specific requirements.

You can use SuiteCloud Development Framework (SDF) to develop your SuiteApp. SDF includes support for SuiteApp projects, self-contained, standalone projects that enable SuiteCloud Developer Network (SDN) members to develop and deploy SuiteApps to their NetSuite accounts. SuiteBundler is used to bundle and share SDF SuiteApps. You can create a bundle that contains all objects from an SDF SuiteApp project without manually adding all of the objects to the bundle in the Bundle Builder. For information about using SDF, see SuiteCloud Development Framework Overview.

The following table lists the topics where you can get more information about these processes:

Topic

Description

SuiteApp Development Terminology

Terminology used to describe the bundle development process.

Which Method Should I Choose?

Description of the different methods used to develop SuiteApps with development accounts. Includes information to decide on the best method for your requirements.

Additional SuiteApp Development Guidelines

Guidelines to use during SuiteApp development.

Single Development Account Method

How to use a single development account to develop SuiteApps.

Multiple Development Account Methods

How to use multiple development accounts in a SuiteApp development environment. The recommended approach depends on how many simultaneous versions of an individual SuiteApp that you want to develop:

SuiteApp Development Terminology

This section uses the following terminology when describing the SuiteApp development process:

Term

Description

development account

Account in which you can develop and test new applications and customizations. For a more detailed description of development accounts, see NetSuite Development Accounts.

development account environment

Set of development accounts used as an environment in which to develop SuiteApps. Each development account is used for a specific purpose in the SuiteApp development process.

target account

NetSuite account into which an administrator installs a bundle.

source account

NetSuite development account from which a bundle is installed into another account.

sandbox account

NetSuite can provision one or more sandbox accounts for use with a production account. For more information, see NetSuite Sandbox.

NetSuite account used for the integration and user acceptance testing of customizations created in a development account environment before installation in a production account.

release account

NetSuite development account dedicated to the release of bundles. A release account can serve as the source account of bundles that customers install into their sandbox or production accounts.

test account

NetSuite development account dedicated to the testing of bundles. Use a testing account to perform QA on NetSuite customizations that were developed in a development account.

develop account

NetSuite development account dedicated to the development of customizations, independent of production customizations or production data.

Which Method Should I Choose?

The following table lists the different development methods and the relative benefits:

Method

Description

Benefits

Drawbacks

Single Development Account Method

Uses a single development account.

The single development account is used for developing, testing, and releasing a SuiteApp.

  • Size. Appropriate for smaller customization projects.

  • Release and update management. Easy to release or update production-ready bundles.

  • Bug fixes. Difficult to release bug fixes for older versions of the bundle.

  • Future releases. If customers do not upgrade in a timely manner to the new version of a bundle, then the capability to jump versions during a future upgrade becomes problematic. For example, it may not be possible to upgrade from version 1.0 of a bundle to version 3.5 of the same bundle.

  • No difference between development and release. No de-coupling of development and release account types. Changes to objects in a bundle in the development account are included in subsequent installations or updates by other accounts.

  • Consistency. No consistent copy of current release version of the bundle.

  • Changed objects affect bundle components. Any change to an object in a bundle affects the behavior of the bundle. So, a change to a single object in a bundle could be installed as an update.

  • No team development. Multiple developers need to work in the same environment.

Single Development Account Environment Method

Uses three development accounts to develop one version of a bundle at a time.

A bundle developer works in one account, stages the bundle for release in a second account, and tests in a third account.

  • Separate accounts. De-couples development, test, and release accounts.

  • Avoids bundle overwrites. Inadvertent overwriting of bundle content more unlikely without using sandbox for testing and release.

  • Testing with production data. Uses sandbox account for user acceptance and integration testing with production data.

  • Bug fixes. Difficult to release bug fixes for older versions of the bundle.

  • No multiple version development. Supports development of only one version of a SuiteApp at a time.

  • Team development. Multiple developers working on a single version of a SuiteApp would be accessing the same account.

  • SuiteApp versioning. Can be difficult to manage SuiteApp versioning between development cycles.

Multiple Development Account Environments Method

Uses two environments, where each environment contains three development accounts. Used to simultaneously develop multiple versions of a single SuiteApp.

In each environment, a bundle developer works in one account, stages the bundle for release in a second account, and tests in a third account.

  • Bug fixes. Can fix bugs in one environment and at the same time develop new version in a separate environment.

  • Separate code bases. Bundle being developed separate from release version.

  • Separate accounts. De-couples development, test, and release accounts.

  • Avoids bundle overwrites. Inadvertent overwriting of bundle content more difficult without using sandbox for testing and release.

  • Testing with production data. Uses sandbox account for user acceptance and integration testing with production data.

  • Team development. Multiple developers working on a single version of a SuiteApp would be accessing the same account.

  • SuiteApp versioning. Can be difficult to manage SuiteApp versioning between development cycles.

Additional SuiteApp Development Guidelines

Important:

Use the following guidelines when developing SuiteApps with the SuiteBundler development methods for development accounts.

Related Topics

SuiteBundler
SuiteBundler Overview
SuiteApp Creation and Distribution
SuiteApp Installation and Update
SuiteApps and Sandbox Accounts
SuiteBundler Pages
Custom Transaction Types in Bundles
Adding a Custom Segment to a Bundle

General Notices