The environment you write X++ in: Visual Studio and Application Explorer replacing the browser script editor and SDF, deployable packages and Azure DevOps replacing SuiteBundler and account customisation, Trace Parser and SQL Insights replacing the governance-unit budget and the Script Execution Log — and an honest account of what NetSuite's tooling still does better.
Chapter 2 was about the language. This chapter is about everywhere else you spend your day: the editor, the pipeline that gets your code into production, the environments you test it in, the debugger, and the tools you reach for when something is slow.
SuiteScript development happens in one of two places: the browser-based script editor built into NetSuite itself, good for a quick edit and immediate visibility into the account, or VS Code with the SuiteCloud extension, which adds IntelliSense-style completion, a project structure, and integration with SuiteCloud Development Framework…
An SDF project's objects/ folder is a flat-ish list of XML object definitions — custom records, fields, scripts, workflows — described by a manifest.xml and deployed per deploy.xml. It is straightforward to reason about because everything in the project is, largely, everything you are shipping.
NetSuite change management has two speeds: SuiteBundler, which packages and versions a set of customisations for publishing across accounts, and direct account customisation, which is simply editing production (or a sandbox) live. Both are fast because NetSuite hosts the runtime and the account state together;
SuiteScript debugging leans on two tools: the SuiteScript Debugger, which attaches to a script execution and lets you step through it, and log.debug() statements, which are cheap enough to leave in production permanently and are read back through the Script Execution Log — an always-on, retrospective record of every execution, its…
NetSuite performance work is anchored in the governance-unit budget and the Script Execution Log: you know exactly how many units a search or a record operation cost, and a slow script is usually a script approaching its ceiling.
This is the least tidy mapping in the whole chapter, because a saved search is not one tool doing one job — it is one tool doing up to four jobs at once: a filtered list view, an exported or emailed report, a dashboard data source, and an ad hoc query surface for a power user.
D365 ships three purpose-built testing layers that a NetSuite-origin team typically has to introduce as new discipline: the SysTest framework for engine-level unit tests against X++ classes, the Regression Suite Automation Tool (RSAT), which records and replays UI-level regression scenarios (particularly valuable across a One Version…
The tools change shape more than the underlying goals do: get code written correctly, get it into an environment safely, find out why something is slow, and get data in front of the people who need it.