afv-library/skills/deployment-readiness-check/SKILL.md
Mohan Raj Rajamanickam 2320c50264
ci: publish skills as @salesforce/afv-skills npm package @W-21534193@ (#30)
* ci: update package details and add GitHub workflows for skills validation and release

* chore: update Node version, change license, and refactor skills validation script to TypeScript

* chore: remove unused deps

* fix: npm package

* fix: flatten skills to pass validation

* chore: add validation script to package.json and update GitHub workflow to use it

* chore: enhance skills validation and update workflows for npm publishing

* refactor: streamline skills validation process in workflow and script

* refactor: improve documentation and structure of skills validation script

* implement checks based on jeff's best practices doc

* chore: add pull request template for skill submissions

* chore: update pull request template with additional references and improve automated checks section

* chore: update pull request template to clarify naming convention with a warning for gerund form

* chore: update pull request template to reference skill authoring guide and enhance checklist structure

* chore: enhance GitHub workflows for skills validation and release process

* refactor: improve parsing logic for SKILL.md files and enhance error collection in validation

* chore: update validation checks to enforce character limits for skill names and descriptions

* fix: remove unnecessary whitespace in footer string in validate-skills.ts
2026-03-12 13:41:52 -07:00

258 lines
8.6 KiB
Markdown

---
name: deployment-readiness-check
description: Comprehensive pre-deployment validation checklist for Salesforce releases. Use before deploying to production to catch metadata issues, test coverage gaps, and configuration errors.
license: Apache-2.0
compatibility: Requires Salesforce CLI, jq, bash
metadata:
author: afv-library
version: "1.0"
allowed-tools: Bash Read
---
## When to Use This Skill
Use this skill before deploying Salesforce metadata to production (or higher environments) to:
- Validate metadata quality and completeness
- Check test coverage meets organizational standards
- Verify security settings and permissions
- Identify configuration issues before deployment
- Generate deployment documentation
## Prerequisites
- Salesforce CLI installed and authenticated to target org
- `jq` command-line JSON processor installed
- Bash shell (Linux, macOS, or WSL on Windows)
- Source metadata in SFDX project format
## Step 1: Run Metadata Validation
Execute the validation script to check for common metadata issues:
```bash
bash scripts/check_metadata.sh
```
The script validates:
- **Metadata format** - Ensures all XML is well-formed
- **API versions** - Checks for outdated API versions
- **Deprecated features** - Identifies deprecated components
- **Naming conventions** - Validates standard naming patterns
- **File completeness** - Ensures meta.xml files are present
Review the output for any warnings or errors before proceeding.
## Step 2: Verify Test Coverage
Check that your Apex test coverage meets organizational standards:
```bash
# Run all tests and generate coverage report
sf apex test run --test-level RunLocalTests --result-format human --code-coverage --wait 10
# Check coverage percentage
sf apex get test --test-run-id <test-run-id> --code-coverage --result-format json | jq '.summary.testRunCoverage'
```
**Minimum requirements**:
- Overall org coverage: ≥75% (Salesforce minimum)
- Individual class coverage: ≥75% (recommended)
- No classes with 0% coverage
If coverage is below threshold:
1. Identify uncovered classes using the coverage report
2. Add test methods to increase coverage
3. Rerun tests until requirements are met
## Step 3: Security and Permissions Review
Review security settings and permissions to ensure proper access controls:
1. **Profile and Permission Set Review**
- Check that custom profiles/permission sets follow least-privilege principle
- Verify admin permissions are not granted to standard users
- Ensure sensitive objects have appropriate FLS
2. **Sharing Rules and OWD**
- Review Organization-Wide Defaults are appropriate
- Validate sharing rules grant necessary access without over-sharing
- Check for public groups with excessive membership
3. **API Access**
- Verify Connected Apps have appropriate scopes
- Check Named Credentials use secure authentication
- Review Remote Site Settings are necessary
Consult the [security checklist reference](references/security_checklist.md) for detailed guidance.
## Step 4: Configuration Validation
Verify configuration settings are deployment-ready:
```bash
# Check for hardcoded URLs or IDs
grep -r "https://.*\.salesforce\.com" force-app/main/default/
grep -r "[a-zA-Z0-9]{15,18}" force-app/main/default/ | grep -v "meta.xml"
# Validate Custom Settings and Custom Metadata
sf project retrieve start --metadata CustomObject:*__c
```
**Configuration checklist**:
- [ ] No hardcoded production URLs in code
- [ ] No hardcoded record IDs
- [ ] Custom Settings configured correctly for target org
- [ ] Custom Metadata Types populated appropriately
- [ ] Email templates reference correct org email
- [ ] Reports and Dashboards folders have correct permissions
## Step 5: Review Dependencies
Check for dependency conflicts or missing components:
```bash
# Generate dependency report
sf project deploy validate --manifest package.xml --test-level RunLocalTests --verbose
# Check for missing dependencies
grep -i "error.*component" deployment_log.txt
```
Common dependency issues:
- Missing Custom Fields referenced in code
- Validation Rules referencing deleted fields
- Workflows or Process Builders using deprecated actions
- Lightning Components with missing design resources
See [dependency troubleshooting guide](references/dependency_resolution.md) for solutions.
## Step 6: Generate Deployment Checklist
Use the deployment checklist template to document your release:
```bash
cp assets/deployment_checklist.md deployment_checklist_$(date +%Y%m%d).md
```
Fill out the checklist with:
- [ ] Deployment date and time window
- [ ] Components being deployed (attach package.xml)
- [ ] Test execution results and coverage
- [ ] Backup verification (data and metadata)
- [ ] Rollback procedure documented
- [ ] Stakeholders notified
- [ ] Post-deployment validation steps
- [ ] Monitoring plan for 24-48 hours
## Step 7: Execute Pre-Deployment Validation
Run a validation-only deployment to catch issues before actual deployment:
```bash
# Validate deployment without committing
sf project deploy validate \
--manifest package.xml \
--test-level RunLocalTests \
--verbose
# Save the validation ID for quick deploy
sf project deploy start --use-most-recent-validation --async
```
**Benefits of validation**:
- Tests run in production environment
- Identifies environment-specific issues
- Generates Quick Deploy ID for faster deployment
- No changes committed until you confirm
Review validation results and address any failures before scheduling deployment.
## Step 8: Prepare Rollback Plan
Document rollback procedures before deploying:
1. **Backup current state**
```bash
sf project retrieve start --manifest package.xml --target-org production
git tag pre-deployment-$(date +%Y%m%d) && git push --tags
```
2. **Test rollback procedure** in sandbox:
- Deploy previous version of metadata
- Verify functionality is restored
- Document any data cleanup required
3. **Establish rollback criteria**:
- Critical bugs found within 2 hours
- Core functionality broken
- Performance degradation >50%
- Data integrity issues
See [rollback procedures reference](references/rollback_procedures.md) for detailed steps.
## Post-Deployment Validation
After successful deployment, verify the release:
1. **Smoke tests** - Execute critical user workflows
2. **Monitor logs** - Check debug logs for errors (24-48 hours)
3. **Query test data** - Verify triggers and automation work correctly
4. **User acceptance** - Confirm with stakeholders functionality works
5. **Performance check** - Review governor limit usage in logs
## Common Issues and Solutions
### Issue: Test Coverage Drops Below 75%
**Cause**: New Apex classes added without sufficient tests.
**Solution**:
1. Run `sf apex test run --code-coverage` to identify gaps
2. Add test methods covering uncovered lines
3. Revalidate coverage
### Issue: Validation Fails with "Component Not Found"
**Cause**: Missing dependency in package.xml.
**Solution**:
1. Review error message for missing component
2. Add component to package.xml
3. Retrieve component from source org if needed
4. Revalidate
### Issue: Permission Errors After Deployment
**Cause**: FLS or object permissions not deployed correctly.
**Solution**:
1. Verify profiles/permission sets are in package.xml
2. Check that CustomObject metadata includes field permissions
3. Deploy profiles separately if needed
4. Use Permission Set Groups for complex permission hierarchies
## Best Practices
1. **Always validate before deploying** - Never deploy directly to production without validation
2. **Run full test suite** - Use RunLocalTests, not NoTestRun
3. **Deploy during maintenance windows** - Minimize impact on users
4. **Communicate with stakeholders** - Notify before, during, and after deployment
5. **Monitor post-deployment** - Watch logs and user feedback for 24-48 hours
6. **Document everything** - Maintain deployment logs and decisions
7. **Use version control tags** - Tag releases for easy rollback
## References
- [Security Checklist](references/security_checklist.md) - Detailed security review steps
- [Dependency Resolution Guide](references/dependency_resolution.md) - Solve dependency conflicts
- [Rollback Procedures](references/rollback_procedures.md) - Step-by-step rollback guide
- [Deployment Checklist Template](assets/deployment_checklist.md) - Reusable checklist
## Automation Opportunities
Consider automating this skill:
- **CI/CD Integration** - Run validation script in pipeline
- **Scheduled Coverage Checks** - Monitor test coverage daily
- **Auto-generated Documentation** - Create deployment notes from package.xml
- **Slack/Email Notifications** - Alert team of deployment status