Now, as you may recall, we are working on a tests branch of our repository. If you go to GitHub, it may offer to create a pull request—a procedure meant to merge your branch into the master branch or any other branch, as in the yellow section of the following screenshot. Even if the interface does not offer this (it won't if there was already a pull request a few minutes before), you can create a pull request yourself, via the New pull request button. See the following screenshot:

Using GitHub, you can request other people to review your changes, comment on them, and more; GitHub will also confirm whether merging is possible or whether you'll need to resolve conflicts first.

While, in our case, we did run our tests locally and we know it is safe to merge, there is no way for others to check that easily. In order to make life simpler for everyone, and save some time for you (for large projects, proper testing might take a while), continuous integration (CI) services are used. Most of the time, all CI services do is trigger on a new commit, pull code to a virtual machine, run your tests, then report back whatever the tests succeeded in determining. Because of CI services' automatic nature, it is easy to run even multiple machines with different environments—say, one service could test your code on Python 3 and one on Python 2.

Generally speaking, CI services do cost money. Most of them, though, have free tiers for open source projects. As our package is open source and open to anyone, let's leverage the free tier of a CI service. There are plenty of great services around, and all of them are more or less the same. We will use Azure pipelines, but you can pick something else if you want.

To get started, we need to go through a few simple steps:

1. First, we need to go to the Azure DevOps website (https://azure.microsoft.com/en-us/services/devops/) and register. We'll give it access to our GitHub account and create a build pipeline for the wikiwwii repository. In a moment, Azure will offer you a few scenarios, starting with Python—this is what we need.
2. Next, it will show a simple pipeline as a YAML file. It will, by default, offer to run multiple instances with different Python versions. We can drop all but 3.7.
3. As we are using poetry, we can replace the pip install line with the command for poetry installation as per Poetry's installation guide. On the next line, the pytest-azurepipelines package is installed. We can't use that, because we need to install it via poetry, so we'll have to add it into the poetry development dependency list. At the same time, there is no sense in having this package locally, so we can mark it as an extra:

poetry add --dev --extras azure pytest-azurepipelines

4. Here is the first step of our pipeline:

script: |
          curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
          source $HOME/.poetry/env
          poetry --version
          poetry install -E azure
          displayName: 'Install dependencies'

5. Now, the second step is simple—just run pytest from within Poetry:

- script: |
           poetry run pytest --cov=wikiwwii tests
           displayName: 'pytest'

6. Last but not least, the default pipeline works on any activity on the master branch. Instead, let's trigger it on a pull request to the master. To do that, just replace the trigger with pr in the YAML:

pr:
- master

And we're done! Now allow Azure to submit that code to the master branch; don't forget to commit the new version of the package with pytest-azurepipelines added. Let's try a pull request.

If everything worked as it is supposed to, GitHub will show a small yellow circle near the last commit in a list in the pull request section. If you hover on it, it will show the current CI status as either queued or running. Once the pipeline runs, the circle will turn either green or red, depending on the results. The following screenshot shows this:

And now we're done with CI. All other CI systems are very similar; most of them use YAML as a declaration of processes, so it is easy to switch between different CI systems if needed.

Up next, let's generate some documentation for our pet project.