Magentrix CLI - Developer Guide

Overview

This guide provides comprehensive workflows, best practices, and advanced techniques for developing with Magentrix CLI. It covers everything from daily development patterns to team collaboration and CI/CD integration.

Target Audience:

Active Magentrix developers
Development team leads
DevOps engineers implementing automation
Teams adopting version control workflows

Development Workflows

Daily Development Cycle

The standard workflow for individual developers working on Magentrix applications.

Morning Routine

Step 1: Sync with Server

# Navigate to project
cd ~/magentrix-project

# Get latest changes from server
magentrix pull

What this does:

Downloads any changes made by teammates
Downloads any changes made through Magentrix IDE
Updates your local files to match server state
Prevents conflicts before you start working

Step 2: Verify Status

magentrix status

Check for:

Conflicts requiring resolution
Unexpected server changes
Current sync state

Example Output:

✓ All files in sync
✓ No conflicts detected
Last Pull: 2024-12-11 09:00:15

Active Development

Option A: Batch Development (Recommended for Multiple Files)

# Edit multiple files in your editor
code .

# Make changes across controllers, pages, classes
# ...

# Review changes before deploying
magentrix status

# Deploy all changes at once
magentrix publish

Benefits:

Efficient for related changes across files
Single compilation on server
Atomic deployment of features
Clear change boundaries

Option B: Real-Time Development (Recommended for Single File)

# Start auto-sync mode
magentrix autopublish

# Edit files - changes auto-upload on save
code src/Controllers/HomeController.ctrl

# Press Ctrl+C when done

Benefits:

Immediate feedback on changes
Good for iterative development
Helpful when learning Magentrix
Real-time compilation error detection

End of Day Routine

# Ensure all changes are published
magentrix publish

# Verify everything is synced
magentrix status

# Expected output: "All files in sync"

Best Practice Checklist:

✓ All changes published to server
✓ No uncommitted version control changes
✓ No conflicts with server
✓ Documentation updated if needed

Real-Time Development Pattern

For developers who want immediate feedback during active coding.

Setup

# Pull latest first
magentrix pull

# Start watching files
magentrix autopublish

Console Output:

🔄 Auto-publish mode started
Watching for file changes... (Press Ctrl+C to stop)

Development Loop

Edit File: Make changes in your editor
Save File: Ctrl+S / Cmd+S
Auto-Upload: CLI uploads automatically
Auto-Compile: Server compiles code
View Results: See compilation status in console

Example Session:

[09:15:23] Changed: src/Controllers/HomeController.ctrl
  ✓ Uploaded (0.8s)
  ✓ Compiled successfully (1.2s)

[09:16:45] Changed: src/Pages/Dashboard.aspx
  ✓ Uploaded (0.6s)
  ✓ Compiled successfully (0.9s)

[09:17:12] Changed: src/Classes/EmailHelper.ac
  ✓ Uploaded (0.7s)
  ✗ Compilation error: Line 42: Syntax error
      Missing semicolon after statement

Error Handling

When compilation fails:

Read Error Message: CLI shows exact line and error
Fix Code: Correct the error in your editor
Save Again: Auto-upload triggers immediately
Verify Success: Check for success message

Stopping Auto-Publish

# Press Ctrl+C in terminal
^C
Auto-publish stopped

# Optionally verify all changes are published
magentrix status

When to Use Real-Time Development:

Learning Magentrix development
Debugging specific issues
Rapid prototyping
Single-file focused work
Testing changes iteratively

When Not to Use:

Making changes across many files
Structural refactoring
Working with slow internet
Changes requiring coordinated deployment

Feature Development Workflow

For developing new features that span multiple files.

Phase 1: Planning

# Pull latest to start fresh
magentrix pull

# Verify clean state
magentrix status

Expected: All files in sync, no conflicts

Phase 2: Create Structure

# Create controller
magentrix create   --type class   --class-type controller   --name ReportController   --description "Report generation functionality"

# Create page
magentrix create   --type page   --name Reports   --description "Reports interface"

# Create helper class
magentrix create   --type class   --class-type utility   --name ReportHelper   --description "Report utility functions"

Result:

src/Controllers/ReportController.ctrl
src/Pages/Reports.aspx
src/Classes/ReportHelper.ac

Phase 3: Development

Edit files in your IDE:

# Open project in VS Code
code .

# Or specific files
code src/Controllers/ReportController.ctrl
code src/Classes/ReportHelper.ac
code src/Pages/Reports.aspx

Develop incrementally:

Build controller logic
Implement helper functions
Create page interface
Add styling and assets

Phase 4: Testing and Deployment

# Check what changed
magentrix status

# Review changes
# Expected: Shows all new and modified files

# Deploy to server
magentrix publish

# Verify deployment
magentrix status

Testing on Server:

Access your Magentrix portal
Navigate to the new feature
Test functionality
Fix issues and republish as needed

Phase 5: Version Control

# Stage changes
git add src/

# Commit with meaningful message
git commit -m "feat: Add report generation functionality

- Added ReportController for handling requests
- Created ReportHelper with PDF generation
- Built Reports page interface
- Added report styling assets"

# Push to repository
git push origin feature/reports

Bug Fix Workflow

For fixing production issues quickly and safely.

Step 1: Reproduce Locally

# Pull latest production code
magentrix pull

# Locate the problematic file
# Check error logs, user reports, etc.

Step 2: Create Fix

For Simple Fixes (Single File):

# Use real-time mode for quick feedback
magentrix autopublish

# Edit file
code src/Controllers/BuggyController.ctrl

# Save and verify compilation
# Fix any errors
# Press Ctrl+C when done

For Complex Fixes (Multiple Files):

# Edit all necessary files
code .

# Make changes
# ...

# Publish all together
magentrix publish

Step 3: Verify Fix

Test in Magentrix portal
Verify bug is resolved
Check for side effects
Test related functionality

Step 4: Document and Commit

# Commit fix
git add .
git commit -m "fix: Resolve null reference in user profile

- Added null check for optional user data
- Fixed exception when profile incomplete
- Added defensive coding patterns

Fixes #123"

# Push to repository
git push origin bugfix/user-profile

Version Control Integration

Git + Magentrix CLI Architecture

Understanding the Two Systems:

┌─────────────────────┐         ┌──────────────────────┐
│   Git Repository    │         │  Magentrix Server    │
│  (Version Control)  │         │   (Deployment)       │
└─────────────────────┘         └──────────────────────┘
          ▲                                ▲
          │                                │
          │ git push/pull                  │ magentrix publish/pull
          │                                │
          └────────────┬───────────────────┘
                       │
              ┌────────▼────────┐
              │  Local Project  │
              │  (Development)  │
              └─────────────────┘

Key Principles:

Git tracks code history - permanent record, branching, collaboration
Magentrix CLI deploys code - live server, compilation, testing
They don't integrate - separate tools, separate workflows
Use both sequentially - commit to Git, then publish to Magentrix

Repository Setup

Initial Setup

# Navigate to your project
cd ~/magentrix-project

# Initialize Git repository
git init

# Configure user
git config user.name "Your Name"
git config user.email "your.email@company.com"

# Create .gitignore
cat > .gitignore << EOF
# Magentrix CLI cache - do not commit
.magentrix/

# Dependencies
node_modules/

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/
.idea/
*.swp
*.swo

# Logs
*.log
EOF

# Add remote repository
git remote add origin https://github.com/yourcompany/magentrix-project.git

# Initial commit
git add .
git commit -m "Initial commit: Magentrix project setup"
git push -u origin main

What to Commit

DO Commit:

src/                      # All source code
├── Classes/
├── Controllers/
├── Triggers/
├── Pages/
├── Templates/
└── Contents/Assets/
README.md                 # Project documentation
.gitignore                # Git ignore rules
package.json              # If using Node packages

DON'T Commit:

.magentrix/               # CLI cache and configuration
node_modules/             # npm dependencies
.env                      # Environment variables
*.log                     # Log files

Daily Workflow with Git

Morning: Sync Both Systems

# 1. Get latest code from Git
git pull origin main

# 2. Get latest from Magentrix server
magentrix pull

# 3. Verify status
magentrix status
git status

During Development: Git First, Magentrix Second

# Make changes to files
# ...

# 1. Commit to Git (version control)
git add src/Controllers/UserController.ctrl
git commit -m "feat: Add user export functionality"

# 2. Publish to Magentrix (deployment)
magentrix publish

# 3. Push to Git remote (collaboration)
git push origin main

Rationale:

Git preserves history before deployment
If deployment fails, you have committed work
Team sees changes in version control
Clear separation of concerns

End of Day: Ensure Both Synced

# 1. Publish to Magentrix
magentrix publish

# 2. Commit to Git
git add .
git commit -m "End of day commit: Work in progress"

# 3. Push to Git
git push origin main

# 4. Verify both systems
magentrix status
git status

Branching Strategy

Feature Branch Workflow

# Create feature branch
git checkout -b feature/user-reports
magentrix pull

# Develop feature
# ...

# Commit frequently
git add .
git commit -m "feat: Add report controller"

# Test on Magentrix
magentrix publish

# More development
# ...

# Complete feature
git add .
git commit -m "feat: Complete user reports feature"

# Push feature branch
git push origin feature/user-reports

# Create pull request for review

After Pull Request Approval

# Switch to main branch
git checkout main

# Pull latest including merged feature
git pull origin main

# Publish merged code to Magentrix
magentrix publish

Team Collaboration Patterns

Developer A: Creates Feature

# Create feature branch
git checkout -b feature/new-dashboard
magentrix pull

# Develop feature
code src/Controllers/DashboardController.ctrl
code src/Pages/Dashboard.aspx

# Commit to Git
git add .
git commit -m "feat: Add new dashboard"
git push origin feature/new-dashboard

# Publish to development server
magentrix publish

# Create pull request

Developer B: Reviews and Integrates

# Fetch latest branches
git fetch origin

# Checkout feature branch
git checkout feature/new-dashboard

# Pull from Magentrix to test
magentrix pull

# Review code, test functionality

# Approve and merge pull request (in GitHub/GitLab)

# Switch to main
git checkout main
git pull origin main

# Publish to production server
magentrix publish

Conflict Resolution

Git Conflicts (Code-Level)

Scenario: Two developers modified the same file.

# Attempting to pull
git pull origin main

# Git reports conflict
Auto-merging src/Controllers/HomeController.ctrl
CONFLICT (content): Merge conflict in src/Controllers/HomeController.ctrl
Automatic merge failed; fix conflicts and then commit the result.

Resolution:

Open conflicted file:

public ActionResult Index()
{
<<<<<<< HEAD
	return View("Dashboard");
=======
	return View("Home");
>>>>>>> origin/main
}

Resolve manually:

public ActionResult Index()
{
	return View("Dashboard"); // Use new version
}

Complete merge:

git add src/Controllers/HomeController.ctrl
git commit -m "Merge: Resolve conflict in HomeController"
git push origin main

Publish resolved version:

magentrix publish

Magentrix Conflicts (Server-Level)

Scenario: File changed both locally and on server.

# Attempting to pull
magentrix pull

# CLI reports conflicts
⚠ Conflicts detected!

The following files have changed both locally and on the server:
  ~ src/Controllers/HomeController.ctrl

Resolution:

Choose resolution strategy:

? How would you like to resolve conflicts?
❯ Manual Review - Review each conflict individually

Review each file:

File: src/Controllers/HomeController.ctrl

Local (modified 2024-12-11 10:00):
  return View("Dashboard");

Server (modified 2024-12-11 11:30):
  return View("Home");

? Resolve this conflict:
❯ Use Server Version
  Keep Local Version

Publish if needed:

# If you kept local version
magentrix publish

Best Practice: Communicate with team to prevent conflicts.

Asset Management

Working with Static Assets

Static assets include CSS, JavaScript, images, fonts, and other non-code files.

Asset Organization

Standard Structure:

src/Contents/Assets/
├── css/
│   ├── main.css
│   ├── theme.css
│   └── components/
│       ├── buttons.css
│       └── forms.css
├── js/
│   ├── app.js
│   ├── utils.js
│   └── vendor/
│       └── jquery.min.js
├── images/
│   ├── logo.png
│   ├── banner.jpg
│   └── icons/
│       ├── user.svg
│       └── settings.svg
└── fonts/
    ├── CustomFont.woff2
    └── CustomFont.woff

Downloading Assets

# Pull all assets from server
magentrix pull

Assets are downloaded to:

src/Contents/Assets/

Folder structure is preserved from server to local.

Adding New Assets

Step 1: Place Files Locally

# Add new image
cp ~/Downloads/new-logo.png src/Contents/Assets/images/

# Add new stylesheet
touch src/Contents/Assets/css/new-theme.css

Step 2: Upload to Server

# Publish includes assets
magentrix publish

Example Output:

Changes to be published:
  Created (2):
    + src/Contents/Assets/images/new-logo.png
    + src/Contents/Assets/css/new-theme.css

? Proceed with publish? (Y/n) Y

✓ Uploading new-logo.png...
✓ Uploading new-theme.css...
✓ Published successfully!

Updating Assets

Step 1: Modify Files Locally

# Edit CSS
code src/Contents/Assets/css/main.css

# Replace image
cp ~/Downloads/updated-banner.jpg src/Contents/Assets/images/banner.jpg

Step 2: Upload Changes

magentrix publish

Binary files (images, fonts) are detected and uploaded efficiently.

Deleting Assets

Step 1: Remove Files Locally

rm src/Contents/Assets/images/old-logo.png

Step 2: Publish Deletion

magentrix publish

Example Output:

Changes to be published:
  Deleted (1):
    - src/Contents/Assets/images/old-logo.png

? Proceed with publish? (Y/n) Y

✓ Deleting old-logo.png from server...
✓ Published successfully!

Supported File Types

Images:

PNG (.png)
JPEG (.jpg, .jpeg)
GIF (.gif)
SVG (.svg)
ICO (.ico)
WebP (.webp)

Stylesheets:

CSS (.css)
SCSS (.scss) - compile locally before upload
LESS (.less) - compile locally before upload

Scripts:

JavaScript (.js)
TypeScript (.ts) - compile locally before upload

Fonts:

WOFF2 (.woff2)
WOFF (.woff)
TTF (.ttf)
OTF (.otf)

Documents:

PDF (.pdf)
TXT (.txt)
JSON (.json)
XML (.xml)

Other:

Any file type Magentrix supports

Asset Best Practices

Organize by Type: Use folders (css/, js/, images/)
Use Meaningful Names: user-avatar.png not img1.png
Optimize Before Upload: Compress images, minify CSS/JS
Version Assets: Use Git to track changes
Document Usage: Note which pages use which assets

Referencing Assets in Code

In ASPX Pages:

<!-- CSS -->
<link rel="stylesheet" href="/Contents/Assets/css/main.css" />

<!-- JavaScript -->
<script src="/Contents/Assets/js/app.js"></script>

<!-- Images -->
<img src="/Contents/Assets/images/logo.png" alt="Logo" />

In Controllers:

// Return asset URL
public ActionResult GetAssetUrl()
{
	var url = "/Contents/Assets/images/banner.jpg";
	return Json(new { assetUrl = url });
}

See: Managing Static Assets for more details.

Conflict Resolution Strategies

Understanding Conflict Types

Type 1: Git Conflicts

Cause: Multiple developers modified same lines in same file.

Occurs: During git pull or git merge.

Resolution: Git merge tools, manual editing.

Example:

<<<<<<< HEAD
Your changes
=======
Their changes
>>>>>>> branch-name

Type 2: Magentrix CLI Conflicts

Cause: File changed locally and on server since last sync.

Occurs: During magentrix pull.

Resolution: CLI conflict resolution wizard.

Example:

⚠ Conflict: src/Controllers/HomeController.ctrl
Local modified: 2024-12-11 10:00
Server modified: 2024-12-11 11:30

Conflict Prevention

Best Practices

Pull Before You Start
```
magentrix pull
git pull
```
Communicate Changes
- Announce when working on files
- Use feature branches
- Coordinate with team
Commit Frequently
- Small, logical commits
- Clear commit messages
- Push regularly
Use Locking for Critical Files
- Coordinate via team chat
- "I'm working on HomeController"
- Wait for "Done with HomeController"

Team Coordination

Example Team Protocol:

Team Chat:
Developer A: "Working on HomeController, ~30 min"
Developer B: "👍 I'll wait"
[30 minutes later]
Developer A: "HomeController published, available now"
Developer B: "Thanks, pulling now"

Manual Conflict Resolution

Magentrix CLI Conflicts

Scenario: File changed both locally and on server.

magentrix pull

CLI Output:

⚠ Conflicts detected! (1 file)

File: src/Controllers/HomeController.ctrl

? How would you like to resolve conflicts?
  Overwrite Local - Replace with server version
  Skip Conflicts - Keep local version
❯ Manual Review - Review individually

Option 1: Overwrite Local (Lose Local Changes)

✓ Overwriting local file with server version
⚠ Your local changes will be lost!

Use when: Server version is correct.

Option 2: Skip Conflicts (Keep Local Changes)

✓ Keeping local file unchanged
ℹ Server changes will be ignored

Use when: Local version is correct, will publish later.

Option 3: Manual Review (Choose Per File)

File: src/Controllers/HomeController.ctrl

Local (modified 2024-12-11 10:00):
  Line 45: return View("Dashboard");

Server (modified 2024-12-11 11:30):
  Line 45: return View("Home");

? Resolve this conflict:
❯ Use Server Version
  Keep Local Version
  Show Full Diff

Use when: Need to review each conflict carefully.

Advanced Conflict Resolution

Using Diff Tools

Step 1: Enable Logs to See Full Diff

magentrix config
# Enable operation logs

magentrix pull

Step 2: Check Conflict Details

cat .magentrix/logs/pull-*.log

Step 3: Use External Diff Tool

# Install diff tool (example: meld)
# Mac: brew install meld
# Linux: sudo apt-get install meld

# Create temporary copies
cp src/Controllers/HomeController.ctrl /tmp/local-version.ctrl
# Get server version (pulled to backup location)

# Compare
meld /tmp/local-version.ctrl /tmp/server-version.ctrl

Step 4: Resolve Manually

Edit the local file with correct merged version, then:

magentrix publish

Advanced Topics

CI/CD Integration

Automated Deployment Pipeline

Use Case: Automatically deploy Magentrix code when changes are pushed to Git.

Prerequisites:

CI/CD platform (Jenkins, GitLab CI, GitHub Actions)
Magentrix API key
Secure secrets management

Example: GitHub Actions

File:.github/workflows/deploy.yml

name: Deploy to Magentrix

on:
	push:
		branches:
			- main

jobs:
	deploy:
		runs-on: ubuntu-latest
		
		steps:
			- name: Checkout code
				uses: actions/checkout@v3
			
			- name: Setup Node.js
				uses: actions/setup-node@v3
				with:
					node-version: '20'
			
			- name: Install Magentrix CLI
				run: npm install -g @magentrix-corp/magentrix-cli
			
			- name: Configure Magentrix CLI
				run: |
					magentrix setup 						--api-key ${{ secrets.MAGENTRIX_API_KEY }} 						--instance-url ${{ secrets.MAGENTRIX_URL }}
			
			- name: Publish to Magentrix
				run: magentrix publish

Setup Secrets:

In GitHub repository settings → Secrets:

MAGENTRIX_API_KEY: Your API key
MAGENTRIX_URL: Your instance URL

Example: GitLab CI

File:.gitlab-ci.yml

deploy_to_magentrix:
	stage: deploy
	image: node:20
	
	script:
		- npm install -g @magentrix-corp/magentrix-cli
		- magentrix setup --api-key $MAGENTRIX_API_KEY --instance-url $MAGENTRIX_URL
		- magentrix publish
	
	only:
		- main

Setup Variables:

In GitLab project settings → CI/CD → Variables:

MAGENTRIX_API_KEY: Your API key (masked)
MAGENTRIX_URL: Your instance URL

Example: Jenkins

Jenkinsfile:

pipeline {
	agent any
	
	environment {
		MAGENTRIX_API_KEY = credentials('magentrix-api-key')
		MAGENTRIX_URL = credentials('magentrix-url')
	}
	
	stages {
		stage('Setup') {
			steps {
				sh 'npm install -g @magentrix-corp/magentrix-cli'
			}
		}
		
		stage('Configure') {
			steps {
				sh '''
					magentrix setup 						--api-key $MAGENTRIX_API_KEY 						--instance-url $MAGENTRIX_URL
				'''
			}
		}
		
		stage('Deploy') {
			steps {
				sh 'magentrix publish'
			}
		}
	}
}

Multi-Instance Management

Managing Multiple Environments

Scenario: Work with Production, Staging, and Development instances.

Setup

# Production instance
mkdir ~/magentrix-production
cd ~/magentrix-production
magentrix setup
# Enter production credentials
magentrix pull

# Staging instance
mkdir ~/magentrix-staging
cd ~/magentrix-staging
magentrix setup
# Enter staging credentials
magentrix pull

# Development instance
mkdir ~/magentrix-development
cd ~/magentrix-development
magentrix setup
# Enter development credentials
magentrix pull

Working with Multiple Instances

# Work on development
cd ~/magentrix-development
code .
# Make changes
magentrix publish

# Test, then promote to staging
cd ~/magentrix-staging
cp -r ~/magentrix-development/src/ ./
magentrix publish

# Test, then promote to production
cd ~/magentrix-production
cp -r ~/magentrix-staging/src/ ./
magentrix publish

Helper Script

File:~/bin/magentrix-switch

#!/bin/bash

case "$1" in
	prod|production)
		cd ~/magentrix-production
		;;
	stage|staging)
		cd ~/magentrix-staging
		;;
	dev|development)
		cd ~/magentrix-development
		;;
	*)
		echo "Usage: magentrix-switch {prod|stage|dev}"
		exit 1
		;;
esac

echo "Switched to $1 environment"
magentrix

Usage:

chmod +x ~/bin/magentrix-switch
magentrix-switch dev
magentrix-switch prod

Performance Optimization

Large Project Optimization

For Projects with 10,000+ Files:

Use Selective Publishing
- Publish only changed files
- CLI automatically optimizes
Batch Asset Uploads
- Upload assets in bulk
- CLI handles this automatically

Enable Operation Logs Strategically

# Disable for routine operations
magentrix config
# Disable logs

# Enable only for debugging

Optimize Network
- Use wired connection when possible
- Ensure stable internet
- Consider ISP bandwidth

Scan Time Optimization

The CLI uses optimized algorithms:

Hash-based change detection: Only uploads actually changed files
Parallel processing: Uploads files concurrently
Incremental updates: Tracks state between operations

Performance Benchmarks:

Files	Scan Time	Upload Time	Total Time
100	< 1s	5-10s	5-10s
1,000	1-2s	10-20s	12-22s
10,000	< 2s	30-60s	32-62s
20,000	< 2s	60-120s	62-122s

💡 Note: These are approximate. Actual times depend on network speed and file sizes.

Troubleshooting Guide

Common Issues and Solutions

Issue: Files Not Uploading

Symptoms:

magentrix publish shows files but doesn't upload
No changes detected when there should be

Solutions:

Check File Permissions

ls -la src/
# Ensure files are readable
chmod -R u+r src/

Verify You're in Correct Directory

pwd
# Should show project directory with src/ folder

Check Status First

magentrix status
# Should show pending changes

Clear Cache and Retry

rm -rf .magentrix/cache/
magentrix status
magentrix publish

Issue: Compilation Errors

Symptoms:

Server rejects code with compilation errors
Errors in CLI output after publish

Solutions:

Read Error Message Carefully
```
✗ Compilation error: Line 42: Missing semicolon
```
- Note the line number
- Note the specific error

Fix Code Locally

code src/Controllers/HomeController.ctrl
# Fix line 42

Test Syntax
- Use IDE syntax checking
- Follow coding guidelines
Republish
```
magentrix publish
```

Issue: Lost Connection During Autopublish

Symptoms:

magentrix autopublish stops responding
Network disconnection

Solutions:

Stop Autopublish
```
# Press Ctrl+C
^C
```

Check Status

magentrix status
# See what wasn't published

Publish Remaining Changes
```
magentrix publish
```
Restart Autopublish if Needed
```
magentrix autopublish
```

Issue: Credential Errors

Symptoms:

"Authentication failed" errors
"Invalid API key" errors

Solutions:

Verify Credentials

magentrix config
# View All Settings
# Check instance URL and API key (masked)

Reconfigure

magentrix setup
# Enter credentials again

Test Connection

magentrix
# Should show connected status

Check API Key Permissions
- Contact Magentrix administrator
- Verify your user has API access

Issue: Conflicts Won't Resolve

Symptoms:

Conflicts persist after resolution
Can't publish or pull

Solutions:

Use Manual Review

magentrix pull
# Choose "Manual Review"
# Resolve each conflict

Force Overwrite

magentrix pull
# Choose "Overwrite Local"
# Re-apply your changes
magentrix publish

Export Local Changes

# Backup your changes
cp -r src/ ~/backup-src/

# Overwrite with server
magentrix pull # Overwrite Local

# Manually merge
# Copy back needed changes
magentrix publish

Debugging with Logs

Enable Detailed Logging

magentrix config
# Select "Log File Settings"
# Enable logging

Run Operation

magentrix pull

View Logs

# List log files
ls .magentrix/logs/

# View most recent pull log
cat .magentrix/logs/pull-*.log | tail -n 100

Log Contents

Logs include:

Detailed timestamps
API calls and responses
File processing details
Error stack traces
Warnings about edge cases

Share Logs for Support

# Compress logs
tar -czf magentrix-logs.tar.gz .magentrix/logs/

# Send to support team

Best Practices Summary

Development Best Practices

Always Pull First
- Start each session with magentrix pull
- Prevents conflicts
- Gets latest changes
Check Status Before Publishing
- Run magentrix status before magentrix publish
- Review changes carefully
- Avoid accidental deployments
Use Version Control
- Commit to Git before publishing to Magentrix
- Write meaningful commit messages
- Push regularly
Test Before Deploying
- Test changes locally if possible
- Use development instance for testing
- Verify in browser after publishing
Use Descriptive Names
- Clear controller names: UserController, not UC1
- Clear page names: UserProfile, not Page1
- Follow team naming conventions
Organize Your Code
- Group related functionality
- Use proper folder structure for assets
- Document complex logic
Backup Critical Work
- Commit to Git frequently
- Keep local backups
- Use multiple branches
Communicate with Team
- Announce when working on shared files
- Use pull requests for code review
- Coordinate deployments

Performance Best Practices

Use Batch Publishing
- Group related changes
- Publish together for efficiency
- Prefer publish over autopublish for multiple files
Optimize Assets
- Compress images before upload
- Minify CSS and JavaScript
- Remove unused assets
Monitor File Count
- Clean up unused files
- Archive old code
- Keep project lean

Security Best Practices

Protect API Keys
- Never commit to version control
- Use environment variables in CI/CD
- Don't share publicly
Use .gitignore Properly
- Exclude .magentrix/ directory
- Exclude sensitive config files
- Review before committing
Limit API Key Scope
- Use minimum necessary permissions
- Rotate keys periodically
- Revoke unused keys

Video Tutorial

[Video Placeholder: Magentrix CLI Developer Guide]

This video covers:

Daily development workflows
Git integration patterns
Team collaboration strategies
Conflict resolution techniques
Performance optimization tips

Additional Resources

Magentrix Platform Documentation

Coding Guidelines

Follow Magentrix coding standards for best results:

C# Coding Guidelines
JavaScript Coding Guidelines
Vue Coding Guidelines

Getting Help

Magentrix CLI Documentation: This guide and command reference
Support: Contact Magentrix support through your portal
Community: Collaborate with your development team

Summary

You've learned:

✓ Daily development workflows with the CLI
✓ Real-time development patterns
✓ Feature development best practices
✓ Version control integration with Git
✓ Team collaboration strategies
✓ Asset management techniques
✓ Conflict resolution strategies
✓ CI/CD integration patterns
✓ Multi-instance management
✓ Performance optimization
✓ Troubleshooting techniques
✓ Best practices for Magentrix development

You're now equipped to develop efficiently with Magentrix CLI!

Table of Contents

Magentrix CLI - Developer Guide

Overview

Development Workflows

Daily Development Cycle

Morning Routine

Active Development

End of Day Routine

Real-Time Development Pattern

Setup

Development Loop

Error Handling

Stopping Auto-Publish

Feature Development Workflow

Phase 1: Planning

Phase 2: Create Structure

Phase 3: Development

Phase 4: Testing and Deployment

Phase 5: Version Control

Bug Fix Workflow

Step 1: Reproduce Locally

Step 2: Create Fix

Step 3: Verify Fix

Step 4: Document and Commit

Version Control Integration

Git + Magentrix CLI Architecture

Repository Setup

Initial Setup

What to Commit

Daily Workflow with Git

Morning: Sync Both Systems

During Development: Git First, Magentrix Second

End of Day: Ensure Both Synced

Branching Strategy

Feature Branch Workflow

After Pull Request Approval

Team Collaboration Patterns

Developer A: Creates Feature

Developer B: Reviews and Integrates

Conflict Resolution

Git Conflicts (Code-Level)

Magentrix Conflicts (Server-Level)

Asset Management

Working with Static Assets

Asset Organization

Downloading Assets

Adding New Assets

Updating Assets

Deleting Assets

Supported File Types

Asset Best Practices

Referencing Assets in Code

Conflict Resolution Strategies

Understanding Conflict Types

Type 1: Git Conflicts

Type 2: Magentrix CLI Conflicts

Conflict Prevention

Best Practices

Team Coordination

Manual Conflict Resolution

Magentrix CLI Conflicts

Advanced Conflict Resolution

Using Diff Tools

Advanced Topics

CI/CD Integration

Automated Deployment Pipeline

Example: GitHub Actions

Example: GitLab CI

Example: Jenkins

Multi-Instance Management

Managing Multiple Environments

Setup

Working with Multiple Instances

Helper Script

Performance Optimization

Large Project Optimization

Scan Time Optimization

Troubleshooting Guide

Common Issues and Solutions

Issue: Files Not Uploading