Best Practices for Collaboration
Introduction
Hasura DDN is engineered to streamline collaboration within and across teams in your organization by directly addressing the inefficiencies with traditional development workflows. When bringing different services together in one API using traditional methods, known as "federation", the complexity of coordinating API changes frequently leads to bottlenecks, risking disruptions to internal customers and, more critically, to end users. Traditional methods, such as manual deployments or siloed development practices, often result in delayed feedback and increased time to market, making it challenging to maintain agility and responsiveness.
By contrast, Hasura DDN leverages near-instant feedback loops facilitated by local development, streamlined data-source composability, and an optimized CI/CD workflow. This approach not only mitigates the risks associated with conventional workflows but also empowers your team to deliver updates with unprecedented speed and reliability.
Recommended deployment workflow
In the following sections, we will outline a recommended deployment workflow for Hasura DDN. This workflow is designed to ensure that your team can iterate quickly and confidently, while also minimizing the risk of disruptions to deployed projects.
While it's assumed you've created a Git repository — or are using some other form of version control — for the steps below to be reproducible, you should initialize a Git repository and commit your project's code to a remote source, such as GitHub.
Develop
Hasura allows for local development to independently and iteratively add functionality to your API. This allows each member on the team to have their own development environment for testing and iteration; this also protects any deployed projects from disruptions.
This means that each developer has their own development environment to which they can iteratively — and confidently — test their changes. As these changes all exist in their metadata, they can then commit these to version control and use familiar git workflows to test and deploy their changes to a deployed project.
A common scenario would be a user updating the permissions for a model. In this case, they would write their permissions in metadata, test them locally using the Hasura DDN console, and then create a new build on Hasura DDN:
ddn supergraph build create --supergraph ./supergraph.cloud.yaml
This ID — and the accompanying URL — can be easily be shared with teammates for easy testing and review.
Then, they can commit the changes:
git add .
git commit -m "Add ModelPermissions to Users model"
git push
Review
With the changes above pushed to the remote repository, a pull request would then be opened. This would allow other team members to checkout the changes and run them from the hosted project's console.
Deploy
Once the PR has been approved and merged, the build can then be applied to the project's endpoint:
ddn supergraph build apply <supergraph-build-version>
Then, the cycle would begin again for further iteration.
Automate deployments
While the steps above can be performed manually, automation is key to ensuring that deployments are consistent and reliable. The Hasura CLI can be used to automate deployments to Hasura DDN, and GitHub Actions can be used to automate the process of running the Hasura CLI.
You can drop this GitHub Action into your repository and configure it to run on merges to specific branches to automate the deployment process 🎉
This Action will take care of not only creating builds for each change to the PR's branch, but also in generating preview links for easy review from teammates.