Specs for Continous Integration and Code Reviews #248
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
See also: https://hackmd.io/g-8QuOAnSQeqnb8PRNjFbQ (ht @bertsky)
|
stweil
suggested changes
Jul 5, 2023
|
|
||
| * GitHub | ||
| * CircleCI | ||
| * Github Actions |
There was a problem hiding this comment.
Suggested change
| * Github Actions | |
| * GitHub Actions |
| * GitLab | ||
| * GitLab CI | ||
|
|
||
| The choice of a CI/CD tools heavily relies on your version control server as well as your project's requirements and your instution's infrastructure. |
There was a problem hiding this comment.
Suggested change
| The choice of a CI/CD tools heavily relies on your version control server as well as your project's requirements and your instution's infrastructure. | |
| The choice of a CI/CD tools heavily relies on your version control server as well as your project's requirements and your institution's infrastructure. |
Comment on lines
+25
to
+36
| - try to keep your pipelines fast to get rapid feedback. some aspects to consider is running the fastest test first (see below), using small images for your Docker containers, and caching your data. | ||
| - your CI/CD pipelines should be furnished with proper unit and integration tests. these should run as one of the first stages in your pipelines in order to detect defects early. | ||
| - the test stage should run on every push to the remote repository in order to make sure that a commit doesn't break anything. | ||
| - commit often in order to detect breaking changes early. | ||
| - run your fastest test first. if they fail, they fail early and save a lot of resources compared to running slower tests first. | ||
| - run your tests locally before running them via pipelines. this will save a lot of resources as well. | ||
| - commit often in order to detect breaking changes early. | ||
| - either minimize your branching model or make sure that the pipelines run on feature/bugfix branches as well. otherwise you might not notice breaking changes in time. | ||
| - ensure that the main functionality of your software is still up and running after having deployed (smoke testing). | ||
| - provide an easy way to rollback in case something goes really wrong, e.g. being able to re-deploy a previous release. | ||
| - reuse existing configuration, e.g. by leveraging CircleCI's orbs or GitLab templates. | ||
| - secure your pipelines. secret variable should be secret, and not everyone in your organization should have admin rights in your CI/CD environment. |
There was a problem hiding this comment.
Suggested change
| - try to keep your pipelines fast to get rapid feedback. some aspects to consider is running the fastest test first (see below), using small images for your Docker containers, and caching your data. | |
| - your CI/CD pipelines should be furnished with proper unit and integration tests. these should run as one of the first stages in your pipelines in order to detect defects early. | |
| - the test stage should run on every push to the remote repository in order to make sure that a commit doesn't break anything. | |
| - commit often in order to detect breaking changes early. | |
| - run your fastest test first. if they fail, they fail early and save a lot of resources compared to running slower tests first. | |
| - run your tests locally before running them via pipelines. this will save a lot of resources as well. | |
| - commit often in order to detect breaking changes early. | |
| - either minimize your branching model or make sure that the pipelines run on feature/bugfix branches as well. otherwise you might not notice breaking changes in time. | |
| - ensure that the main functionality of your software is still up and running after having deployed (smoke testing). | |
| - provide an easy way to rollback in case something goes really wrong, e.g. being able to re-deploy a previous release. | |
| - reuse existing configuration, e.g. by leveraging CircleCI's orbs or GitLab templates. | |
| - secure your pipelines. secret variable should be secret, and not everyone in your organization should have admin rights in your CI/CD environment. | |
| - Try to keep your pipelines fast to get rapid feedback. Some aspects to consider are running the fastest test first (see below), using small images for your Docker containers, and caching your data. | |
| - Your CI/CD pipelines should be furnished with proper unit and integration tests. These should run as one of the first stages in your pipelines in order to detect defects early. | |
| - The test stage should run on every push to the remote repository in order to make sure that a commit doesn't break anything. | |
| - Commit often in order to detect breaking changes early. | |
| - Run your fastest test first. If they fail, they fail early and save a lot of resources compared to running slower tests first. | |
| - Run your tests locally before running them via pipelines. This will save a lot of resources as well. | |
| - Commit often in order to detect breaking changes early. | |
| - Either minimize your branching model or make sure that the pipelines run on feature/bugfix branches as well. Otherwise you might not notice breaking changes in time. | |
| - Ensure that the main functionality of your software is still up and running after having deployed (smoke testing). | |
| - Provide an easy way to rollback in case something goes really wrong, e.g. being able to re-deploy a previous release. | |
| - Reuse existing configuration, e.g. by leveraging CircleCI's orbs or GitLab templates. | |
| - Secure your pipelines. Secret variable should be secret, and not everyone in your organization should have admin rights in your CI/CD environment. |
|
Meanwhile this PR is older than a year. Is there any chance that it will be merged (with my suggestions)? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We briefly talked about those in the Tech Call today and decided to make these part of the spec, hence this PR.
I took the liberty of updating the list of CI providers (we do not use Travis CI anymore, but we do use Github Actions), otherwise they are unchanged from @mweidling's inital drafts.