♾️CI/CD

Learn how Sedai works with CI/CD workflows to ensure changes to your codebase are regularly integrated, tested, and deployed.

The adoption of continuous integration (CI) and continuous deployment (CD) workflows is increasingly common in software delivery. While this automated approach has several advantages, it poses some challenges to systems like Sedai that makes runtime scaling decisions to enhance or maintain application performance and cost efficiency. These decisions usually require adjustments to resource allocation, limits, and scaling strategies, which may conflict with configurations defined in your CI/CD workflow. To address these differences in delivery models, Sedai provides the following options to complement GitOps workflows so that you can leverage the benefits of continuous optimization and autonomous management:

Autonomously managed resource allocation (recommended)

This option is similar to how a resource's auto scaling configuration is handled. In this approach, the declarative state of compute resources ignores changes related to resource allocation and scaling (such as replica count, CPU, and memory). Dynamic production runtime parameters, including resource allocation/scaling, are excluded in your Git repository. Instead, the source of truth records that resource allocation/scaling is handled by Sedai during runtime. Most CI/CD tools provide options to selectively ignore changes happening to specific fields in runtime.

Sedai Sync

With this approach, there's no need for changes in your software delivery workflow. Sedai automatically detects resource releases. The CD workflow does not need to recognize the changes made by Sedai and can continue to safely overwrite the resource allocation values. Sedai will automatically reset a resource's configuration to its identified ideal values after detecting the release. However, this approach is effective only when the workflow overwrites values during new releases and may not work well with tools like Argo CD, which continuously monitor and synchronize the resource state based on the source of truth.

Sedai API for resource what it should be (WISB)

Sedai maintains ideal resource configurations once it has sufficient data to analyze behavior. You can use REST APIs to query Sedai's optimal resource configurations and send these to tools like Argo CD or update the source of truth in your Git repository. This process can be performed periodically (poll-based) or triggered when there's a new release. (Note: This approach may require additional scripting in the resource delivery workflow.)

Notification

This approach serves as an alternative to the poll-based approach. Sedai sends an alert (in JSON or YAML format) that details changes made or recommended by Sedai. The benefit of this option is its timeliness and flexibility as you can send notifications via a webhook integraiton.

Git pull request

Sedai integrates with infrastructure as code (IaC) providers and can periodically create pull requests (PRs) in your Git repository with details of all of its resource changes. The PR format can be either:

  • Standard Format: By default, these PRs contain data in a standard format that incorporates all resource modifications made by Sedai. You can opt to include the full WISB (i.e., all changes made by Sedai and the unaltered configuration) or only the changes made by Sedai. Keep in mind that you would need to review PRs using an automated or manual process and incorporate changes in your Git repository where resource state is defined.

  • Custom Format: Provide your own PR data format that compliments your preferred Git source format (such as Terraform Templates, Helm & Kubernetes YAMLs, etc.). This approach requires relevant files and variables governing the attributes managed by Sedai. Given the inherent flexibility of custom IaC solutions, this type of integration is typically done directly with the Sedai team.

Learn more about IaC integrations:

🖥️pageInfrastructure as Code (IaC)pageResource to IaC File Mapping

Last updated