Quick SummaryCI/CD stands for **continuous integration and continuous delivery **and is a set of best practices that define how new logic is tested and deployed.While fully automated CI/CD is not available today in Xano, we have a number of features designed to replicate the most important pieces of the concept, outlined below.Each feature mentioned below offers its own in-depth documentation, which we also recommend reviewing.
CI/CD Explained
CI/CD is a technique used in software development to make the process of updating applications faster and more reliable. CI, or Continuous Integration, involves regularly adding small updates to the codebase, helping developers catch and fix errors quickly. CD, or Continuous Delivery, ensures these updates can be automatically tested and deployed to production environments seamlessly. Together, these practices help deliver new features and improvements to users more efficiently, ensuring a better, more stable experience. In Xano, you can think of any function stacks you’re building as your codebase. Features such as branching/merging, unit and workflow tests, and triggers can all play a role in building a seamless CI/CD-style workflow in Xano for you and your team.Achieving CI/CD in Xano
1
Build your Dev, Stage, and Prod Environments
Typically, you’ll have at least three environments for proper development.
- Dev - This is where you build updates and new features
- Stage - This is where you deploy changes and initiate testing to ensure they work as expected, and there are no new bugs or regressions (old bugs returning) introduced
- Prod - This is the production environment that serves the live experience to your users
- Launch / Self-Serve Plans: Use Branching & Merging and create separate branches for dev, stage, and prod. Your frontend should typically only be calling production endpoints, but you can also deploy a second frontend for testing that defaults to stage or dev
- Scale or Enterprise Plans with Xano Link: Deploy your changes to separate workspaces using Xano Link
- Enterprise Plans with Tenant Center: Create separate tenants in your Tenant Center for each environment, and deploy releases to them
2
Build Tests
You should always be building tests for your function stacks using our Unit Tests and Test Suites features. Unit Tests are designed to run a test on a single function stack (such as a sign-up API), and Test Suites (Workflow Tests) are designed to check what would be a typical multi-step flow for your application (such as a user signing up, purchasing a subscription plan, and receiving a confirmation email).To ensure full coverage, make sure that your tests not only check for positive results, but they also check for proper error handling when things go wrong. The goal is not necessarily to achieve 100% success, but to achieve 100% coverage for all possible scenarios.
3
Deploy Changes to Stage & Test
Deploy your changes to Stage and run your Unit Tests and Test Suites to ensure everything is behaving as expected.If you have tests that fail, it would be recommended to head back to your development environment and make any corrections necessary, and deploy those new changes back to Stage to test again.
4
Pushing to Production
Once you’ve confirmed that your tests pass and you have full coverage, you can push your changes to your production branch or environment.
How do tests impact my database?Test Suites create a duplicate copy of your database, temporarily, just for testing. So, if your production database is large or complex, you may have trouble completing your tests or experience additional complications. It is strongly recommended to utilize Data Sources to navigate around this potential issue.You can also run tests with no database (Empty) if a database is not necessary for that specific test, or if your tests can run from an empty database, such as if they’re only adding data that isn’t used later anywhere.
Additional Notes
Managing Environment Variables
If you’re working with external services, you may require different configurations between your development, stage, and production environments, such as different API keys. Typically, you’d store these in your Environment Variables.- If you’re using Branching/Merging, you’ll be limited to storing all environment variables together. You can use statements like Get Environment Variables to manually parse all available environment variables and retrieve the ones necessary depending on the branch you’re on.
- If you’re using Xano Link, each workspace can contain its own environment variables, and no additional logic is necessary.
- If you’re using Tenant Center, you have the ability to manage each tenant’s environment variables from the Tenant Center. Each tenant can contain its own environment variables, and no additional logic is necessary.