Deployment Decision Guide
Choose the right deployment method for your situation. This guide helps you decide between CI/CD Pipeline, Single File Upload, and Manual Deployment.
Quick Decision Flowchart
Method Comparison
| Factor | Single File Upload | CI/CD Pipeline | Manual Deploy |
|---|---|---|---|
| Speed | Fastest (seconds) | Medium (1-5 min) | Slow (manual steps) |
| Audit Trail | None | Full history | Partial |
| Rollback | Manual | Automated | Manual |
| Team Visibility | None | Full | Limited |
| Best For | Quick fixes, debugging | Features, releases | One-time setups |
Method 1: Single File Upload
Best for: Quick iterations, debugging, temporary changes, urgent hotfixes.
When to Use
| Scenario | Example |
|---|---|
| Debugging | Adding log.debug() to trace an issue |
| Hotfix | Critical bug affecting production now |
| Testing | Trying a quick code change |
| Support | Temporary diagnostic logging |
| Quick config | Changing an email address urgently |
How It Works
┌──────────────────────────────────────────────────────────────────────────┐
│ SINGLE FILE UPLOAD WORKFLOW │
└──────────────────────────────────────────────────────────────────────────┘
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Edit │────►│ Upload │────►│ Test │
│ locally │ │ to NS │ │ in NS │
└──────────┘ └──────────┘ └──────────┘
│
Takes seconds
Commands
# VSCode: Right-click file → "Upload File to Account"
# CLI: Upload single file
suitecloud file:upload --paths "/SuiteScripts/my_script.js"
# CLI: Upload to specific account
suitecloud file:upload --paths "/SuiteScripts/my_script.js" --account "Production"
Important Rules
- Temporary changes only - Don't leave debug code in production
- Commit after if permanent - If the fix stays, push to Git and let CI/CD sync
- One file at a time - For multiple files, use CI/CD instead
Method 2: CI/CD Pipeline
Best for: New features, multi-file changes, team collaboration, production releases.
When to Use
| Scenario | Example |
|---|---|
| New feature | Inventory alert system (3+ scripts) |
| Library update | Changing shared utils.js |
| Production release | Deploying tested code from sandbox |
| Team project | Multiple developers working together |
| Compliance | Need audit trail of all changes |
How It Works
┌──────────────────────────────────────────────────────────────────────────┐
│ CI/CD PIPELINE WORKFLOW │
└──────────────────────────────────────────────────────────────────────────┘
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Commit │────►│ Push to │────►│ CI/CD │────►│ Auto │
│ code │ │ GitHub │ │ validates│ │ deploy │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│
Takes 1-5 min
Triggers
| Branch | Action |
|---|---|
feature/* | Validate only (PR check) |
develop | Auto-deploy to Sandbox |
release/* | Deploy to QA/UAT |
main | Deploy to Production (with approval) |
Benefits
- Consistent deployments every time
- Full audit trail in Git history
- Automatic rollback capability
- Team visibility into all changes
- Prevents "it works on my machine" issues
Method 3: Hybrid Approach
Best for: Critical production issues that need immediate fix AND proper tracking.
When to Use
- Production is broken and needs immediate fix
- Can't wait for CI/CD pipeline
- But still need proper audit trail
How It Works
┌──────────────────────────────────────────────────────────────────────────┐
│ HYBRID WORKFLOW: Fix First, Formalize After │
└──────────────────────────────────────────────────────────────────────────┘
STEP 1: IMMEDIATE FIX
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Fix code │────►│ Upload │────►│ Verify │
│ locally │ │ to Prod │ │ working │
└──────────┘ └──────────┘ └──────────┘
│ Takes seconds
│
▼
STEP 2: FORMALIZE
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Commit │────►│ Push to │────►│ CI/CD │
│ fix │ │ main │ │ syncs │
└──────────┘ └──────────┘ └──────────┘
Syncs all environments
Commands
# Step 1: Immediate fix to production
suitecloud file:upload --paths "/SuiteScripts/broken_script.js" --account "Production"
# Step 2: After verifying fix works, commit and sync
git add .
git commit -m "fix: resolve null reference in invoice processing"
git push origin main
# CI/CD now deploys to all environments
Real-World Scenarios
Scenario 1: Debugging a Script
Situation: User Event script fails silently. Need to add logging to find the issue.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Debug Script │
├──────────────────────────────────────────────────────────────────────────┤
│ Problem: Invoice approval script fails for certain customers │
│ Need: Add log statements to trace the issue │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: Single File Upload
Reason:
├─► Quick iteration (upload → test → repeat)
├─► Changes are temporary
├─► Debug code should NOT be committed
└─► CI/CD would slow you down
Workflow:
1. Add log.debug() statements
2. Upload file to sandbox
3. Trigger the script in NetSuite
4. Check execution log
5. Repeat until issue found
6. Remove debug logs
7. Upload clean version
Scenario 2: Critical Production Bug
Situation: Invoices aren't sending emails. Business is impacted. You found the bug.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Critical Production Bug │
├──────────────────────────────────────────────────────────────────────────┤
│ Problem: Null reference error in email script │
│ Impact: All invoice emails failing │
│ Fix: Single line change │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: Hybrid (Upload → then CI/CD)
Reason:
├─► Production down = fix immediately
├─► Single file upload is fastest
├─► CI/CD ensures other environments sync
└─► Maintains audit trail
Workflow:
1. Fix the code locally
2. Upload directly to Production
3. Verify emails working
4. Commit the fix
5. Push to main (CI/CD syncs all)
Scenario 3: New Feature Development
Situation: Building a new inventory alert system with multiple scripts.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: New Feature │
├──────────────────────────────────────────────────────────────────────────┤
│ Feature: Inventory Alert System │
│ Components: │
│ • Scheduled Script (check inventory) │
│ • User Event (update on save) │
│ • Suitelet (dashboard) │
│ • Custom Record (configuration) │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: CI/CD Pipeline
Reason:
├─► Multiple interdependent files
├─► Custom objects need deployment order
├─► Team should review code
├─► Must test in sandbox first
└─► Need audit trail
Workflow:
1. Create feature branch
2. Develop and commit
3. Push → CI validates
4. Create PR for review
5. Merge to develop → deploys to sandbox
6. Test in sandbox
7. Merge to main → deploys to production
Scenario 4: Shared Library Update
Situation: Adding new functions to utils.js used by 10+ scripts.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Library Update │
├──────────────────────────────────────────────────────────────────────────┤
│ File: utils.js (shared library) │
│ Used by: 10+ scripts across the project │
│ Change: Adding new date formatting functions │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: CI/CD Pipeline
Reason:
├─► High risk (bug affects ALL dependent scripts)
├─► Needs regression testing
├─► Code review can catch issues
└─► Rollback via Git if problems
⚠️ DO NOT use Single File Upload because:
├─► If upload has bug → 10+ scripts break
├─► No easy rollback
└─► No testing before production
Scenario 5: Config Change
Situation: Need to change notification email from old@company.com to new@company.com.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Config Change │
├──────────────────────────────────────────────────────────────────────────┤
│ Change: Email address in notification script │
│ Risk: Low (simple string change) │
└──────────────────────────────────────────────────────────────────────────┘
🤔 DEPENDS on urgency and audit requirements
IF urgent + no audit needed:
┌────────────────────────────────────────────────────────────────────┐
│ ✅ Single File Upload │
│ suitecloud file:upload --paths "/SuiteScripts/notification.js" │
│ Then commit for record-keeping │
└────────────────────────────────────────────────────────────────────┘
IF not urgent OR audit required:
┌────────────────────────────────────────────────────────────────────┐
│ ✅ CI/CD Pipeline │
│ Commit → Push → Auto-deploy │
└────────────────────────────────────────────────────────────────────┘
Scenario 6: Support Diagnostic Logging
Situation: Customer reports intermittent issue. Support needs detailed logs to diagnose.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Temporary Diagnostic Logging │
├──────────────────────────────────────────────────────────────────────────┤
│ Need: Add detailed logging for support ticket #12345 │
│ Duration: Until issue is diagnosed (temporary) │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: Single File Upload
Reason:
├─► Temporary change (will be removed)
├─► Quick turnaround for support
├─► Should NOT be committed
└─► Customer waiting
Workflow:
1. Add detailed log statements
2. Upload to production
3. Ask customer to reproduce
4. Analyze logs
5. Remove diagnostic logging
6. Upload clean version
⚠️ NEVER commit diagnostic logs to repository
Scenario 7: Sandbox Refresh Recovery
Situation: Sandbox was refreshed from production, all customizations gone.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Sandbox Refresh │
├──────────────────────────────────────────────────────────────────────────┤
│ Event: Dev sandbox refreshed from production │
│ Result: All SDF customizations overwritten │
└──────────────────────────────────────────────────────────────────────────┘
✅ USE: CI/CD (Manual Trigger)
Reason:
├─► Need full project deployment
├─► Correct deployment order guaranteed
├─► Matches Git (source of truth)
└─► One-click recovery
How:
GitHub → Actions → "Deploy to Sandbox" → Run workflow
Scenario 8: Schedule Time Change
Situation: Scheduled script runs at 6 AM, needs to run at 8 AM.
┌──────────────────────────────────────────────────────────────────────────┐
│ SCENARIO: Change Script Schedule │
├──────────────────────────────────────────────────────────────────────────┤
│ Change: Execution time from 6 AM to 8 AM │
└──────────────────────────────────────────────────────────────────────────┘
❌ NOT Single File Upload (schedule isn't in script file)
❌ NOT CI/CD (unless using deploy.xml)
✅ USE: NetSuite UI
How:
1. NetSuite → Customization → Scripts
2. Find the script
3. Edit the deployment
4. Change schedule
5. Save
IF using Infrastructure as Code (deploy.xml):
┌────────────────────────────────────────────────────────────────────┐
│ ✅ Use CI/CD │
│ Update deployment XML → commit → push │
└────────────────────────────────────────────────────────────────────┘
Decision Summary Table
| Scenario | Method | Key Reason |
|---|---|---|
| Debugging with log statements | Single File Upload | Temporary, quick iteration |
| Critical production bug | Hybrid (Upload → CI/CD) | Speed + audit trail |
| New feature (3+ files) | CI/CD Pipeline | Code review, proper testing |
| Shared library update | CI/CD Pipeline | High risk, needs testing |
| Urgent config change | Single File Upload | Speed, low risk |
| Non-urgent config change | CI/CD Pipeline | Audit trail |
| Temporary diagnostic logs | Single File Upload | Should not be committed |
| Sandbox refresh recovery | CI/CD Pipeline | Full project deployment |
| Script schedule change | NetSuite UI | Not a code change |
| First-time deployment | CI/CD or Manual | Project setup needed |
Related Documentation
- GitHub Actions CI/CD - Complete CI/CD workflow templates
- Deployment Workflow Guide - Manual deployment methods
- Deploy to Sandbox - Sandbox deployment details
- Deploy to Production - Production deployment details