Start app development

Now that your environment is set up, let's create your first app modification and deploy it to see the development workflow in action.

Your first app modification

Step 1: Choose an app to modify

Navigate to any app folder in your repository. Apps typically follow the naming pattern app-* (e.g., app-org-task, app-timesheet).

# List available apps
ls app-*

Step 2: Make a simple change

Let's modify the app's title as a test. Open the package.json file and update the title:

app-org-task/package.json

{
  "comindApp": {
    "icon": "life-ring",
    "publishingAlias": "TICKET",
    "titlePlural": "Tickets",
    "titleSingular": "Ticket changed title"
  }
  // ...rest of the file
}

Step 3: Deploy to development

Install your modified app to a development workspace:

# Deploy to the DEMO workspace on your dev site
npx comind install app-org-task DEMO

Step 4: Verify the changes

1. Open your development site in a browser, e.g. https://your-org-dev.comindwork.com
2. Navigate to the DEMO workspace
3. You should see your app with the updated title

Understanding the deployment workflow

Comind uses a branching strategy to ensure safe deployments:

Development branch (main)

• Purpose: Active development and testing
• Auto-deployment: Changes automatically deploy to your development site (e.g. https://your-org-dev.comindwork.com)
• When to use: For all feature development and testing

Workflow:

# Make your changes
git add .
git commit -m "Update task app title"
git push origin main

Production branch (prod)

• Purpose: Production-ready releases only

• Auto-deployment: Changes automatically deploy to production (e.g. https://your-org.comindwork.com)

• Requirements:

  • Only admin users can push directly
  • All commits must be signed
  • Usually updated via Pull Request from main

  Creating a Pull Request:

  • Press Ctrl-Shift-P and type "github pull request" to find the command:

  

  • Then create a Pull Request of main to prod

  

Workflow for production:

# Create PR from main to prod (recommended)
# OR admin direct push:
git checkout prod
git merge main
git push origin prod

Deployment process

Branch	Trigger	Destination	Requirements
main	Push/merge	Development site	None
prod	Push/merge	Production site	Admin access + signed commits

Production deployments

Only push to prod when you're confident the changes are ready for end users. Production deployments are permanent and affect real user data.

Custom CI/CD pipelines

Need additional validation steps? You can create custom GitHub Actions workflows to add:

• Automated testing
• Code quality checks
• Security scans
• Approval workflows