Defining the CI/CD Stages

You can define as many CI/CD stages as you need and associate them to a Saagie platform. You can then create and assign specific Git branches for each platform.

A branch is like a local copy of the code that allows teams to make changes to the same source code files in parallel without slowing each other down. You can create as many branches and Saagie platforms as you need, according to your CI/CD workflow definition. You can then assign branches to your Saagie platforms.

  1. Define your CI/CD stages.

  2. Create Git branches according to your CI/CD workflow definition.

  3. Assign branches to your Saagie platforms.

Examples of Git Branch Configurations

Let’s say you have two platforms on Saagie, the DEV and the PROD platform. Here are three examples of configurations:

Example 1. Case #1

In the first case, branches named with the prefix feature are dedicated to the DEV platform. These branches are directly committed to the DEV platform. Then, the DEV platform is committed to the PROD platform.

This case is intended for Intermediate users, using development best practices.
Example 2. Case #2

In the second case, the feature branches previously mentioned are not directly committed to the DEV platform. They are committed to the DEV branch, which is then committed to the DEV platform. Then, the DEV platform is committed to the PROD platform.

This case is included in the example of case #3.
Example 3. Case #3

In the third case, the feature branches are committed in a personal Saagie project located on the DEV platform. These personal projects are a kind of private workspace, which are committed to a global project on the DEV platform. Then, the DEV platform is committed to the PROD platform.

This case is intended for Advanced users who do not want to share their local experiences with other project members in the first instance.

For more information, see Example For Advanced Users (Case #3).

Example For Advanced Users (Case #3)

This example focuses on case #3, which comprises three CI/CD stages with two Saagie platforms, the DEV and PROD platforms.

Your CI/CD stages will define the configuration of your Git branches, and the configuration of your branches will define your GitHub Actions workflows. You must have one GitHub Action per CI/CD stage.

In our case, we have three CI/CD stages. Three stages mean three levels of branches, the feature, DEV, and PROD branches, and therefore three GitHub Actions. The PROD branch can be the trunk of your hierarchical structure.

You can add other platforms, such as a PREPROD platform. To do this, you will have to add a stage to your CI/CD workflow, create the corresponding preprod.json configuration file in the /saagie/envs subdirectory, and create a dedicated GitHub Action workflow file. Then, create the Git branch(es) and make the connection with your platform.

You can add as many .json files to the /saagie/envs subdirectory as you have Saagie platforms. Then, create as many branches as you have platforms, and as many feature branches as you have private projects. Think of the PROD branch as the trunk of the hierarchical structure.

The configuration of case #3 can be as follows:

  1. The test phase: Branches named with the prefix feature are dedicated to the DEV platform. The feature branches are committed in a personal Saagie project located on the DEV platform. These personal projects are a kind of private workspace. With this personal project on Saagie, you can test the development of your code as if you were in local, since you are the only person with access to your project, apart from the administrator.

    • Admin rights can be removed by the administrator themselves.

    • You can establish a naming convention to differentiate private projects from other projects.

  2. The development phase: These personal projects are committed to a global project on the DEV platform.

  3. The production phase: Then, the DEV platform is committed to the PROD platform.