Release Flow
The Fusion Project Portal project relies on two key elements, namely changesets and Radix actions, to facilitate its release process.
To ensure that the code meets our standards, we have a requirement in place: every change made to our codebase must be submitted as a pull request. This step helps maintain the quality of our code.
When you begin working on new code, we recommend starting with a draft pull request. This means that the pull request is not finalized but serves as a work-in-progress. Additionally, it's a good practice to keep the pull request in draft mode while you update its title and description.
When you're ready for your code to be reviewed by others, you can switch the pull request to "ready for review" status. At this point, our system automatically takes the information within the pull request and creates a changeset, which is a record of the modifications made in that pull request. This streamlined process helps manage and document changes effectively.
Pull request template
Here is the pull request template provided for your reference:
# Description
> Please include a summary of the change and which issue is fixed.
> List any external dependencies that are required for this change.
- [ ] PR title and description are to the point and understandable
- [ ] I have performed a self-review of my own code'
Please select version type the purposed change:
- [ ] major
- [ ] minor
- [ ] patch
- [ ] none <!--- Creates an empty changeset -->
External Relations
- [ ] database migration
## Changeset
<!--- Write your changeset here -->
In a pull-request you're asked to provide a clear and concise description of the changes you're making. Here's a breakdown of what's expected:
Summary of Change: Start by summarizing what your code changes are all about. What problem are you addressing or what new feature are you adding? This summary should provide a high-level understanding of the purpose of your changes. Fixing Issues: If your changes are related to a specific issue or bug, mention it here. This helps maintain a clear connection between your code changes and the problem they're intended to solve. External Dependencies: If your code relies on any external resources or dependencies, make sure to list them here. This information is crucial for others reviewing your code to understand the prerequisites and potential impacts.
Self review
Following these points, there are two checkboxes:
PR Title and Description: Ensure that the title and description of your pull request are straightforward and easy for others to understand. This is essential for effective communication. Self-Review: Before submitting the pull request, it's a good practice to perform a self-review of your code. This helps catch any obvious issues or mistakes before others review it.
Version change
Next, you're asked to select the type of version change associated with your code modifications:
- Major: If your changes introduce significant, potentially breaking alterations to the codebase.
- Minor: If your changes add new features or enhancements without causing significant disruptions.
- Patch: For small fixes or minor updates that don't introduce new features.
- None: Use this option if your changes don't impact the version, such as documentation updates or non-code changes.
External Relations
A checkbox for "Database Migration." This is relevant if your changes involve modifications to the database schema or data structures. and wil add information tag to the changeset.
[!IMPORTANT] This change requires database migration.
Changeset
This section serves as a critical part of our changelog, making it accessible to end users. Here, it's crucial to provide a comprehensive explanation of the modifications made and features added. Your goal is to offer users a clear and thorough understanding of what has changed and what they can expect from the latest update.
If a version other than "none" is selected, it's mandatory to include a changeset. Failure to do so will result in errors during the pipeline process.
The Merge
When merging a proposed change, ensure that a changeset has been added. If a changeset is created, a Fusion Project Portal Release will be automatically generated. This portal consolidates all changesets and keeps track of the version that should be released.
Additionally, please note that the pull request will be initially set as a draft upon creation.
Production Release
To initiate the production release process, follow these steps:
- Put the
Fusion Project Portal Releasepull request in "ready for review" status. - Review the changes and perform any necessary actions, such as database migrations if required.
- Approve the pull request.
- After approval, perform a squash merge of the change.
- This action will trigger a pipeline for promoting the Radix pod from the testing environment to the production environment.
By following these procedures, we ensure a systematic and controlled approach to releasing changes to our production environment.