__ __ __ / /_ ____ / /_ __ __ _____ ____ ____/ / ___ _____ / __/ / __ \ / __ \ / / / / / ___/ / __ \ / __ / / _ \ / ___/ / /_ / /_/ / / /_/ / / /_/ / _ / /__ / /_/ // /_/ / / __/ (__ ) \__/ \____/ /_.___/ \__, / (_) \___/ \____/ \__,_/ \___/ /____/ /____/

__ __ / /_ ____ / /_ __ __ / __/ / __ \ / __ \ / / / / / /_ / /_/ / / /_/ / / /_/ / \__/ \____/ /_.___/ \__, / _ /____/ (_) __ _____ ____ ____/ / ___ _____ / ___/ / __ \ / __ / / _ \ / ___/ / /__ / /_/ // /_/ / / __/ (__ ) \___/ \____/ \__,_/ \___/ /____/

Written on 2019-12-29

This is an overdue post wherein I link to to a talk I gave to the Concourse London User Group about the different patterns for operating Concourse for multiple users groups.

The talk was uploaded by Engineer Better to their YouTube channel.

Context

Concourse is an open-source, continuous thing-doer which I use almost every day, and has changed the way I think about software development.

Concourse is usually deployed for continuous integration and delivery, and can be deployed for small teams, or can be deployed in various multi-tenant configurations for larger teams and organisations. These different strategies are covered in the video.

The actual code we use to deploy Concourse at GDS, which represents one of the multi-tenant strategies, is open source on GitHub.