Cookiecutter Template for circleci BuildJobs

Cookiecutter Template for a CircleCI, Continuous integration/Continuous delivery Pipeline, for different types of projects. Using Tox for abstraction the the Process workflow, from the project specific buildsteps.

Current Version: 0.12.0

Features

• Handle Semantic Versioning of the project. (planed)

• Create a Github Releases. (planed)

• Push generated sphinx page to GithubPage. (planed)

• Create GitHub Based Cangelog with ferrarimarco/docker-github-changelog-generator. (planed)

Usage

Install cookiecutter to your local machine.

Example usage

(cookiecutter) $ cookiecutter https://github.com/nolte/cookiecutter-circleci.git
generate_tox_file [n]: y
generate_sphinx_doc [n]: y
project_slug []: cookiecutter-example-build
Select project_type:
1 - cookiecutter
Choose from 1 [1]: 1

Result

(cookiecutter) $ tree
.
└── cookiecutter-example-build
    ├── .circleci
    │   └── config.yml
    ├── docsRequirements.txt
    └── tox.ini

2 directories, 3 files

Index

Advanced Usage

For generate, or replace the CircleCI pipeline of a existing project, use the -f option, and use the foldername as project_slug.

cookiecutter https://github.com/nolte/cookiecutter-circleci.git --checkout develop

Danger

Be carefull when the config are generated to a existing project. Existing files will be overwrite.

Creating the .circleci/config.yml Job Configuration.

Template Variables

generate_tox_file

generating a tox.ini build script

generate_sphinx_doc

add required steps for generate sphinx documentation

project_slug

project folder name

project_type

type of the project artefact, like cookiecutter, ansible roles, etc.

currently supported: cookiecutter

Development

Project Structure

Base Directory Structure

.bumpversion.cfg

Config file for bumpversion handled the semantic versioning process. More information at the Development Process description.

.circleci/config.yml

Used CircleCI for handle the Build, Testing, Releasing and Publishing steps.

Status:

ci-scripts

Folder for ci utility scripts like, install selenium.

docs

This project is documentated with sphinx-doc. The generated deployment will be published to ReadTheDocs and nolte.github.io.

Status:

.github

This folder is used form the GitHub Issue Templates.

it-tests

This Folder contains Selenium based pytest integrations tests. Runned after a nolte.github.io/cookiecutter-circleci deployment.

tests

Test for checking the CookieCutter Template generated projects, based on pytest and pytest-cookies.

tox.ini

Using tox for handle the different build and test configs.

Important Tox Environments

Tox Environment	Description
{py27,py36}-test	Start the local builds, used pytest-cookies for testing the cookiecutter template, see Unit tests.
docs	Generate the html sphinx-doc. All required dependencies are listed in requirementsDocs.txt
py36-{github,readthedocs-latest,readthedocs-stable}-integrationtests	Start the Selenium Integration Tests for existing deployments, some type of Smoke Tests, see Integrations tests.

.travis.yml

Build config for the TravisCI Job, used for testing different python versions.

Status:

Development Process

Branch Modell

As Branchmodel we use a mix of Gitflow and pull-requests. Gitflow is used for the Release Process, the master branch present the latest Published Release. PullRequests are used for integrate external changes and feature branches into the Develop Branch.

Feature Branch

New features will be develop in feature branches like feature/integrate-cuberite.

Warning

Please dont use use feature/* branches in your production Environment.

Develop Branch

The develop branch contains the latest unrelesed version from the template, mostly stable ;)

Release Branch

Master Branch

The master present the latest published release.

Build

Testing

Static tests

For the Static Tests we use flake8, this will check the style. The cofiguration can found at the tox.ini

Unit tests

Integrations tests

Releasing

You can start the Release process with some commit like:

git commit --allow-empty -m "[GradeUP][skip travis] grade up the branch"
git push origin develop

With pushing this commit the Release Pipeline will started automatically.

The Process

• Update the version to new Release, see Versioning

• create the Release Branch

• prepare the Develop Branch branch for next version.

• Create Github Release

• Publish Github Page

• execute Integrations tests

• delete the Release Branch

Versioning

This project follows semantic versioning.

In the context of semantic versioning, consider the role contract to be defined by the role variables.

• Changes that require user intervention will increase the major version. This includes changing the default value of a role variable.

• Changes that do not require user intervention, but add backwards-compatible features, will increase the minor version.

• Bug fixes will increase the patch version.

Publishing

Github Release

Github Page