Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added best practices for CI/CD #5875

Closed
wants to merge 3 commits into from
Closed

Added best practices for CI/CD #5875

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ff79dcc
Added best practices for CI/CD
neelshah2409 Oct 21, 2024
45da6f8
Update docs/user_guide/flyte_fundamentals/registering_workflows.md
neelshah2409 Oct 22, 2024
c8af4b1
Update registering_workflows.md
neelshah2409 Oct 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/user_guide/flyte_fundamentals/registering_workflows.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
neelshah2409 marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated it


- **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.
- **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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this one is clear enough. Maybe we can replace this with a reference to the Registration patterns section

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some examples for it with reference to Flyte workflow.


## What's next?

In this guide, you learned about the Flyte demo cluster, Flyte configuration, and
Expand Down
Loading