Continuous_Integration

In projects with more than one developer, in most cases each person will have a local copy of the source code they are working on. Integrating these local copies into a common repository may not be trivial if these copies diverge significantly.

The state-of-the-art methodologies in software development advodate for integrating as often as reasonable, usually several times per day. This approach is commonly named Continuous Integrations. Some times refered as CI or CI/CD (CD stands for Continuous Deployment).

Continuous Integration in pratice is implemented with a central repository (remember than git is a distributed version control system). Everybody pushes to this repository, and everybody fetches from it. And this central repository is used for the build, running the tests, the docs, linting the code, and anything that can be automated to asses the quality of the code.

Historically, the build was executed once per day (or few times per day) and it took a decent amout of time (possibly few hours) to complete. Developers checked the build after they integrated their changes to the central repository, and fixed any problems after the central repository build was "broken".

Today, with much faster computational power, the workflow is in general different. Developers don't usually push directly to the central repository, but to a branch, and they open pull requests (a diff from the branch to the central repository managed by platforms like GitHub). This allows for code reviews from other developers, but as important, Continuous Integration systems can run on the branches, and the status of the build can be review before the proposed changes are integrated into the central repository. Following this procedure, the central repository build should be green at all time (there are exceptions).

Historically, the most popular CI systems for open source projects were Jenkins and TravisCI. While still popular, in this sprint is recommended to use Azure pipelines from Microsoft. Azure pipelines provides more computational power in the CI servers for open source projects, and is also able to build and test the package in the three main operating systems (Linux, Windows and MacOS).

The CI should be responsible for:

• Running the tests
• Linting the code (validating the good code practices like PEP-8 with packages like pylint or flake8)
• Running the benchmarks
• Building the docs (or simply validate that nothing is broken when building)
• Anything else that can be automated