This post has been republished via RSS; it originally appeared at: Azure Data Explorer articles.
Compute workload team has a lot of logic encapsulated in Kusto stored functions. But since most of the development happens right in Kusto, we hit issues where a developer would make a mistake directly editing the function and it would mess up our production assets. We wanted a way to do code reviews on Kusto functions and have some safeguards in place, but there wasn’t an easy way to pull the entire database schema to the local file system in an easily reviewable format.
This is where Sync Kusto comes in handy. The tool lets the user pick either the local file system or a Kusto database as either the source or the target. The Compare button checks both schemas and determines the delta between the source and the target. After viewing the differences, the user can put a checkmark next to the ones they want to publish and then press the Update button.
Here’s the process that our team uses:
- We have a production database and a development database. The development database has the same schema as the production database, but generally data only lives in the production database and all the functions reference the data in the production database. Our entire schema lives in our repo.
- The developer makes and tests all changes in the development database.
- Once they are satisfied, the developer uses Sync Kusto to pull the changes to their local repo. The source is the development database and the target is their local repo file path.
- After the changes are in the local repo, the developer pushes a new branch and goes through the normal code review process.
- Once the pull request is approved, the developer opens Sync Kusto again. This time the source is their local repo (fully synced master branch) and the target is the production Kusto database. The developer presses Compare, verifies that all the changes are expected and then presses Update to deploy the changes.
For an added safety measure, our team also removes any direct human access to the production database. Only an AAD app has Admin permission on the production database and the key for the app id is stored in Azure Key Vault. Our team has access to the key but it stops us from accidentally making changes in the wrong database when we’re doing our development.
This tool is now available for everyone on GitHub: https://github.com/microsoft/synckusto. We hope that this is useful to you and look forward to your feedback and contributions!