[Docs] document ci/cd best practices

[samhita-alla]

Description

document some general ci/cd best practices discussed by Bernhard in this conversation:: https://discuss.flyte.org/t/15853851/hi-team-i-d-like-to-understand-a-little-more-about-best-prac#1eaa0ca8-d3ec-49a9-9f46-b8537c610cb3

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[dosubot]

🤖

Hi @samhita-alla!

I'm Dosu, a bot here to assist you while we wait for a human maintainer. I can help you solve bugs, answer questions, and guide you in becoming a contributor. I'm here to make your experience smoother. Let's get started!

Based on the conversation you've referenced and the current practices in the Flyte repository, here are some general CI/CD best practices:

1. Use of GitHub Actions for workflow automation: GitHub Actions is used to automate the release process in the Flyte repository. This includes generating git tags, building Docker images, publishing these images, and releasing Helm and manifest files. You can see this in action in the create_release.yml workflow file.

2. Use of secrets for authentication: GitHub secrets are used to store sensitive data like the GitHub token (FLYTE_BOT_PAT) and username (FLYTE_BOT_USERNAME). This keeps sensitive data secure and not exposed in the code.

3. Use of matrix strategy for parallel execution: The matrix strategy is used in the publish-flyte-component-image job. This allows for parallel execution of tasks, in this case, for different components of Flyte.

4. Use of Docker for building and publishing images: Docker is used to build and publish images for the release version. This is evident in the build-docker-images, publish-flyte-binary-image, and publish-flyte-component-image jobs.

5. Use of Helm for package management: Helm is used to manage the Kubernetes packages. This is evident in the helm-release job where Helm is installed and used to prepare the Flyte Helm release.

6. Use of GoReleaser for releasing Go applications: GoReleaser is used in the manifest-release job to automate the release process for Go applications. This includes creating the release on GitHub, building the Go binaries, and creating the release notes.

These practices are not specific to Bernhard but are common best practices for CI/CD in software development. If you have any specific questions about these practices or if there's something else you'd like to know, feel free to ask.

For more information, you can refer to the create_release.yml workflow file in the Flyte repository.

Sources

• .github/workflows/create_release.yml

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[Murdock9803]

Hello @samhita-alla @davidmirror-ops,
I would like to take up this issue and contribute to the org. Please assign the issue to me 🙌

[davidmirror-ops]

@Murdock9803 you're tackling multiple issues, let us know when you need any help or have questions. Thanks!

[Murdock9803]

Sure, I'll ask for any needed context 🙌

[Murdock9803]

@davidmirror-ops Since this is my first time adding a document to the codebase, I'd like to know where should I add the document. I tried to thoroughly read the codebase, and found that docs directory can be used. In this, docs/user_guide/basics/ is a good place I believe ?

Also, instead of adding a whole new page, we can add a section in existing pages ? like Deployment Page

[davidmirror-ops]

@Murdock9803 right, I think adding a section to this page may work

[neelshah2409]

Hey @davidmirror-ops
I would also like to work on this issue.

[davidmirror-ops]

@neelshah2409 There you go. Thanks for volunteering. While @Murdock9803 has been working on this, whoever submits the first accepted PR gets the points.