Added best practices for CI/CD #5875
Conversation
Signed-off-by: Neel Shah <[email protected]>
|
Thank you for opening this pull request! 🙌 These tips will help get your PR across the finish line:
|
| @@ -365,6 +365,15 @@ two GitHub actions that facilitates this: | |||
| of Flyte packages, for example, the `.tgz` archives that are created by | |||
| `pyflyte package`. | |||
|
|
|||
| ## Some of the best practices for CI/CD | |||
There was a problem hiding this comment.
It's important to add a disclaimer-like intro. Something like " In case your development process registers Flyte workflows on each commit, consider the following recommendations" or something along these lines. We don't want users to infer that this is the only way of doing CI/CD with Flyte.
| - **Employ a standard naming scheme for the main and released versions** : This will provide uniformity and clarity. For example, main-<short-commit-hash> for the main version and <version-number> for the released versions. | ||
| - **Automate the process of deployment and build** : The consistent and dependable building and pushing of the Docker image and the registration of the Flyte processes are guaranteed by automating the build and deployment process. | ||
| - **Adapt the registration domain to the commit type** : Workflows are registered in the appropriate environment when the registration domain is modified according to the kind of commit (feature branch, main, or released version). | ||
| - **Adopt a uniform strategy for registration and serialization** : Flyte workflows are serialized and registered using a defined process, which guarantees consistent and dependable workflow registration. |
There was a problem hiding this comment.
I don't think this one is clear enough. Maybe we can replace this with a reference to the Registration patterns section
There was a problem hiding this comment.
Added some examples for it with reference to Flyte workflow.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5875 +/- ##
=======================================
Coverage 36.71% 36.71%
=======================================
Files 1304 1304
Lines 130081 130081
=======================================
Hits 47764 47764
Misses 78147 78147
Partials 4170 4170
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Co-authored-by: David Espejo <[email protected]> Signed-off-by: Neel Shah <[email protected]>
Signed-off-by: Neel Shah <[email protected]>
|
@davidmirror-ops please review the PR. |
| - **Using a consistent versioning strategy**: Use a consistent versioning strategy across different types of commits (feature branches, main, released versions) to ensure that versions are unique and identifiable. | ||
| - **Use a combination of branch name and commit hash for versioning** : Using a combination of branch name and short commit hash (e.g. <branch-name>-<short-commit-hash>) provides a unique and descriptive version identifier for feature branches. | ||
| - **Employ a standard naming scheme for the main and released versions** : This will provide uniformity and clarity. For example, main-<short-commit-hash> for the main version and <version-number> for the released versions. | ||
| - **Automate the process of deployment and build** : The consistent and dependable building and pushing of the Docker image and the registration of the Flyte processes are guaranteed by automating the build and deployment process. | ||
| - **Automate the process of deployment and build** : The consistent and dependable building and pushing of the Docker image and the registration of the Flyte processes are guaranteed by automating the build and deployment process.For example, you can use a GitHub Actions workflow to automate the build and deployment process. |
There was a problem hiding this comment.
I think this is too opinionated and not part of the thread that motivated the original issue.
For example, the flytectl register action we typically use in examples (https://github.com/unionai-oss/flyte-register-action?tab=readme-ov-file#flyte-register-action) follows a different process and most likely every organization will have a different CI/CD system, not even mentioning a different GH Actions setup (if they happen to use GHA).
| - **Adapt the registration domain to the commit type** : Workflows are registered in the appropriate environment when the registration domain is modified according to the kind of commit (feature branch, main, or released version). | ||
| - **Adopt a uniform strategy for registration and serialization** : Flyte workflows are serialized and registered using a defined process, which guarantees consistent and dependable workflow registration. | ||
| - **Adopt a uniform strategy for registration and serialization** : Flyte workflows are serialized and registered using a defined process, which guarantees consistent and dependable workflow registration.For example, you can use the flyte register command to register workflows, and use a consistent naming convention for workflow versions. |
There was a problem hiding this comment.
I'd refer here to the Registration patterns documentation that provides greater detail on it.
| - **Adopt a uniform strategy for registration and serialization** : Flyte workflows are serialized and registered using a defined process, which guarantees consistent and dependable workflow registration. | ||
| - **Adopt a uniform strategy for registration and serialization** : Flyte workflows are serialized and registered using a defined process, which guarantees consistent and dependable workflow registration.For example, you can use the flyte register command to register workflows, and use a consistent naming convention for workflow versions. | ||
| ``` | ||
| import flyte |
There was a problem hiding this comment.
Not sure this is a known pattern
|
@neelshah2409 could you take a look at the comments I left? |
Tracking issue
Closes #4685
Why are the changes needed?
Check all the applicable boxes