¶ Understanding Configuration Versioning and Revisions
Every CDN Distribution in Kintify includes a powerful configuration versioning system that helps you track, manage, and restore changes to your Distribution settings. This guide explains how versioning works and how to use it effectively.
Every time you update your Distribution's configuration, Kintify tracks changes to:
- Origin URL settings
- Host header configurations
- SSL/TLS verification settings
- Host header forwarding
- Redirect handling
- Security settings (root path access, POST requests)
- Referrer allow/block lists
- IP blocking rules
- Logging settings
- Each configuration change creates a new revision
- Revisions are numbered sequentially (1, 2, 3, etc.)
- Each environment (staging/production) tracks its revision number separately
- The current revision number indicates which configuration version is active
For each revision, Kintify stores:
- The complete configuration at that point in time
- Who made the change
- When the change was made
- A comment explaining the change
- Which environments were affected (staging, production, or both)
When making configuration changes, you should always include a descriptive comment that explains:
- What changed
- Why the change was made
- Any important considerations
- Expected impact
Example comments:
"Updated origin URL to new backend server"
"Added IP blocking rules for suspicious activity"
"Enabled SSL verification for improved security"
You can view the complete history of changes to your Distribution, including:
- All past configurations
- When each change was made
- Who made each change
- The comments associated with each change
- Which environments were affected
If a configuration change causes issues, you can:
- Review previous revisions
- Select a known good configuration
- Restore that configuration to either:
- Staging environment only
- Both Staging and Production
- Be specific about what changed
- Explain why the change was made
- Note any dependencies
- Include relevant ticket or issue numbers
- Make changes in Staging first
- Verify the configuration works
- Document any issues
- Roll back if needed before affecting production
- Periodically review revision history
- Look for patterns in changes
- Identify frequently modified settings
- Clean up unnecessary test configurations
- Know which revisions worked well
- Document known good configurations
- Test rollback procedures in staging
- Keep notes about configuration dependencies
- Make changes in staging environment
- New revision is created for staging
- Test thoroughly
- Apply to production when ready
- New revision is created for both environments
- Review revision history
- Identify last known good configuration
- Restore that revision to staging first
- Test the restored configuration
- Restore to production if needed
- Make security-related changes
- Add detailed comments about security impact
- Note any dependencies or requirements
- Monitor results after applying changes
-
Always Add Comments
- Future you will thank present you
- Helps others understand your changes
- Makes troubleshooting easier
- Supports compliance requirements
-
Review Before Restoring
- Check dependencies between changes
- Verify the configuration is still valid
- Test in staging first
- Monitor results after restore
-
Keep Good Records
- Note which revisions work best
- Document any issues encountered
- Track patterns in changes
- Maintain change logs
-
Use Staging Effectively
- Test all major changes
- Verify rollbacks work
- Document test results
- Plan production updates
Q: How many revisions are kept?
A: Kintify maintains a complete history of all configuration changes.
Q: Can I delete old revisions?
A: No, all revisions are preserved for audit and rollback purposes.
Q: Do revisions affect billing?
A: No, revisions and configuration history are included in your service.
Q: Can I compare revisions?
A: Yes, you can view the differences between any two revisions.
Remember: Configuration versioning is your safety net for managing Distribution changes. Use it wisely by adding clear comments, testing in staging, and maintaining good documentation of your changes.