Best Practices
Best practices for implementing Kosli in DevOps workflows for optimal compliance and deployment tracking
Flow Organization
One Flow Per Deployable Unit
Create separate flows for each independently deployable application:
โ Good:
payment-api
user-service
notification-worker
web-frontendโ Bad:
all-microservices # Too broad
backend # Too vagueFlow Naming Conventions
Use consistent, descriptive names:
<team>-<service>-<component>
examples:
- platform-auth-api
- payments-processing-worker
- customer-web-appEvidence Collection Strategy
Collect Evidence Early
Report evidence as soon as it's available:
Don't wait until deployment to report all evidence.
Required Evidence Types
At minimum, collect these evidence types:
Test Results - Prove testing occurred
Security Scans - Prove vulnerability scanning
Code Review - Prove peer review (PR approval)
Build Info - Link to CI/CD build
Evidence Completeness
Ensure all artifacts have complete evidence before production deployment:
Deployment Tracking
Always Report Deployments
Report every deployment, not just production:
Use Exact Artifact References
Ensure the artifact name reported matches exactly what's deployed:
Report Deployment Timing
Report deployments at the right time:
Environment Snapshots
Regular Snapshots
Snapshot environments regularly to detect drift:
Snapshot After Deployment
Always snapshot after deploying to verify:
Multiple Namespaces
Snapshot all relevant namespaces:
Security and Authentication
Secure API Token Storage
โ Store in CI/CD secrets
โ Use environment variables
โ Rotate tokens every 90 days
โ Never commit tokens to code
โ Don't log tokens
Least Privilege
Use dedicated service accounts:
Create separate tokens for each CI/CD system
Name tokens descriptively: "GitHub Actions - payment-api"
Revoke unused tokens
Performance Optimization
Parallel Evidence Collection
Collect evidence in parallel when possible:
Batch Operations
Don't make unnecessary API calls:
Error Handling
Graceful Degradation
Don't fail deployments if Kosli is temporarily unavailable:
Note: Only use if your compliance requirements allow deployments without tracking.
Alerting on Failures
Alert teams when Kosli reporting fails:
Compliance and Audit
Audit Trail Documentation
Ensure complete audit trails:
Artifact fingerprint - Cryptographic proof of what was built
Test evidence - Proof testing occurred and passed
Security evidence - Proof of vulnerability scanning
Review evidence - Proof of code review
Deployment record - When, where, and by whom
Policy as Code
Define compliance policies explicitly:
Regular Compliance Reports
Generate compliance reports regularly:
Team Adoption
Start Small
Begin with a single application/flow:
Week 1: Report artifacts and deployments
Week 2: Add test evidence
Week 3: Add security scan evidence
Week 4: Add code review evidence
Week 5: Implement environment snapshots
Document Your Setup
Create team documentation:
Monitor Adoption
Track Kosli usage metrics:
% of deployments with Kosli tracking
Average evidence count per artifact
Time from build to deployment
Drift detection alerts
Common Pitfalls
โ Don't: Report Wrong Artifact Names
โ Do: Use consistent references
โ Don't: Skip Environment Snapshots
Snapshots verify what's actually running - don't skip them.
โ Don't: Report After Failed Deployments
Only report successful deployments:
Real-World Example
Scenario: SaaS company with 20 microservices, SOC 2 requirement
Implementation:
Results:
100% deployment tracking
Complete SOC 2 compliance
Zero manual documentation
Passed audit on first attempt
Next Steps
Last updated