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.

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.

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. You should adhere to these best practices. 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.

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 better approach depends on how many simultaneous versions of an individual SuiteApp that you want to develop: Single Development Account Environment Method Multiple Development Account Environments Method

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. 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.

• NetSuite follows a phased release schedule for each new version. The phasing process from initial release until the point where all customers are using the new release occurs over several weeks. During the phasing periods, developers, particularly ISVs, must coordinate the installation and update of bundles to ensure that bundles requiring new features are installed into upgraded accounts.

  For more information, see Bundle Support during NetSuite Release Phasing.

• You can use managed bundles to streamline the process of updating and supporting your bundles. For details, see Managed Bundles Overview. ISVs must join the SuiteCloud Developer Network to obtain the appropriate development and testing accounts. See the SuiteCloud Developer Network page on the NetSuite website.

• The development methods described in this section are not intended for bundles developed in sandbox accounts. For information about developing bundles in sandbox accounts, see Sandbox Bundle Deployment Models.

• If you use SuiteScript 2.0 from a development account, make sure that you review and set an appropriate module scope for scripts using a JSDoc tag. To successfully import a SuiteScript 2.0 script created in a development account into another account (such as your NetSuite production or sandbox account), the script must include the following JSDoc Tag:

                /**
  *@NModuleScope Public 
  
              

  For more information, see SuiteScript 2.x JSDoc Validation and NetSuite Development Accounts and Module Scope.

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