How EKWIS uses GitHub Actions for Salesforce delivery

Salesforce work often starts as an operational request rather than a neat software specification. Risk grows when the request, org-side configuration, local metadata, test evidence and production release become separate stories.

EKWIS uses an issue-led GitHub workflow so managed-support changes and larger project work can follow the same engineering path. Checks and approvals increase with risk; the trace from request to release remains intact.

The delivery record starts before code

1. Capture the customer request, current behaviour, target outcome and acceptance criteria.
2. Confirm the repository, Salesforce org, environment and current deployment baseline.
3. Create a short-lived branch linked to the issue or support case.
4. Retrieve or build the smallest coherent metadata change.
5. Review the local diff, including related metadata and destructive effects.
6. Run the narrowest tests that give meaningful confidence, then validate against the correct target org.
7. Open a pull request with the reason for the change and its verification evidence.
8. Release through the approved branch and record the deployment result against the original work item.

What GitHub Actions should automate

• Install a pinned, reviewed Salesforce CLI toolchain.
• Authenticate with environment-scoped secrets and an explicitly named target.
• Check metadata structure, static analysis and repository-specific rules.
• Select and run Apex, Lightning Web Component or other tests appropriate to the change.
• Validate the deployable source or manifest against the intended Salesforce org.
• Publish concise results, failures and deployment IDs back to the pull request or release job.
• Require the configured human approval before a production release.

Reusable workflows help projects share a baseline, but environment details should stay explicit. Production and non-production jobs need separate secrets, approval rules and target resolution even when the underlying workflow is the same.

Use deltas as a review aid, not as the whole truth

A Git diff helps reviewers see what changed, but Salesforce metadata contains dependencies that are not always obvious from changed files. A delta package can reduce noise and deployment size; it still needs review for profiles, permission sets, flows, object fields, destructive changes and components generated or changed together.

• Compare the branch with the correct release baseline, not an arbitrary previous commit.
• Include newly required dependencies that do not appear in the initial file selection.
• Treat destructive metadata as a separate, explicit decision.
• Keep data changes, post-deployment configuration and manual steps beside the metadata release plan.
• Use a full manifest or broader validation when the delta cannot represent the change safely.

Testing should follow the risk

Running every available test on every commit can slow feedback without improving confidence. Running too little pushes uncertainty into production. The pull request should explain why the selected tests cover the changed behaviour, with broader validation applied where Salesforce or release policy requires it.

• Run directly related Apex tests for fast development feedback.
• Add tests for shared services, triggers or flows touched indirectly by the change.
• Use Salesforce deployment test levels that are valid for the target environment and payload.
• Test user-facing behaviour in an org when metadata validation alone cannot prove the outcome.
• Keep test and validation failures visible instead of converting them into warnings to get a green build.

Where AI assists

AI can help turn discovery notes into a first issue draft, trace related metadata, produce an initial implementation, suggest tests and review a pull-request diff for likely gaps. It is useful because it can inspect more context quickly, not because it is allowed to make the release decision.

A developer remains accountable for architecture, permissions, data exposure, test coverage and the decision to deploy. AI findings should point to the relevant file, behaviour or evidence so a reviewer can verify them.

What the customer should be able to see

• What was requested and what was deliberately left out.
• Which Salesforce components changed and why.
• How the behaviour was tested and against which environment.
• Whether the production deployment completed and what follow-up remains.
• A usable status in the support portal or project record without exposing internal build noise.

The result is a faster route for substantial Salesforce change, with enough evidence for the customer and developer to understand what reached production.