Patterns for Continuous Integration

Build Status PyPI version Coverage Status Documentation Status

Travis CI

Focus on Travis CI.

Patterns for Continuous Integration with Docker using Travis CI - Part. 1

Warming up: for each commit on the master branch we want to build a Docker image according to a given Dockerfile and push it on Docker Hub (or different Docker Registry) using Travis CI.

Warming up

Patterns for Continuous Integration with Docker using Travis CI - Part. 2

The “Docker repo” pattern: create two separate Git repositories: one for Docker release and another for software development. This keeps the Docker-specific code isolated from the actual software. Developers can continue working on the source software as usual, while the production Docker image is developed separately

The “Docker repo” pattern

This keeps the Docker-specific code, which could be considered a deployment detail, isolated from the actual software. Developers can continue working on the source software as usual, while the production Docker image is developed separately.

Git repository for software development

Team uses different branches for development and, a certain point, pull-requests for merge the master branch are done. For each one of them, committing the master branch: - modifying the version number in setup.py, a new release will be created on the package repository (e.g. PyPI), - Travis CI builds, tests and packages the software by using py.test and measuring code coverage of Python code. - if such tests are successful: - code coverage stats are published on coveralls.io through coveralls, - Travis CI does a release of the software by uploading the package to the package repository (e.g. PyPI), - Travis CI does two new docker development images, e.g. e59cbe8-develop (image for last commit on master branch) and develop (the official develop image of the project), on the Docker Registry, e.g. Docker Hub.

Git repository for Docker release

When a new development release (e.g. 0.3.9.dev0) is ready and tested for production (see Patterns for Continuous Integration with Docker using Travis CI 2 - Dev. Repo for more details), someone updates consequently the requirements.txt file and commits on master. In this way: - Travis CI builds, tests and packages the software, - Travis CI does two new docker development images, e.g. 0.3.9.dev0 (the image of the development release tagged for production, for archiving purpouse) and latest (the production image of the project), on the Docker Registry, e.g. Docker Hub.