Additional Resources
These are some additional resources to consider while open sourcing your project
Last updated
These are some additional resources to consider while open sourcing your project
Last updated
Open source CI/CD tools are developed to assist users in automating the procedures between a developer checking in code and releasing that code into production.
With CI/CD approach, developers are able to discover defects or bottlenecks in their early stages to avoid integration and deployment issues caused by frequent source code commits
GitLab is an open-source CI/CD tool for managing several areas of the software development lifecycle. The core product is a web-based Git repository manager that includes features like issue tracking, analytics, and a Wiki.
To use GitLab CI/CD, developers have to host the codebase in a Git repository and provide the scripts for building, testing, and deploying in a YAML file named “.gitlab-ci.yml” in the root directory. (NO)
Github Actions / Dependabot are some examples of in-built Github ci/cd tools.
Static analysis tools (aka: Static application security tools - SAST) are carried out on a software product in a non-runtime environment.
This means that it is unnecessary to execute a program for the analysis tool to debug the software.
Code errors are hard to manually detect: Static analysis can find them quite easily, and with accuracy.
It saves developers time as the tool pinpoints quality issues such as coding standard violations, programming errors, and security weaknesses before even running the program. Read more
These questions are pertaining to the changes submitted through Issues and Pull Requests since it is an open source project.
How are these contributions from various developers going to be integrated into your project?
These questions should ideally be outlined in your Contributing Guidelines file or Governance file or be present somewhere in your repository.
Who reviews it?
How often?
Who needs to sign off before it’s accepted?
When should a contributor expect to hear from you?
How can contributors get commit access, if at all?
While creating a governance file, you will have to lay out how the project is expected to be governed. The two most important points to note while doing so are:
Do we want to hold office hours every week?
Do we want to publicly track who is (or isn’t) making contributions to the project?
Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.
You can view a sample governance file here.