Git Workflow Using One Repository Across Multiple Instances — Development, Staging, and Production

Looker will not be updating this content, nor guarantees that everything is up-to-date. 


Starting in Looker 7.12, you can deploy any Git commit SHA, tag, or branch to production with Advanced Deploy Mode. This helps consolidate repositories in multi-environment developer workflows, where each environment points to a different version of a codebase. It also gives greater control to one or a few developers or administrators over the changes that are deployed to production.
 

Motivation


By setting up a Git workflow across multiple Looker hosts, we can create a dedicated development environment for developers to work in, all while shielding users from being exposed to any experimental code. All development and code review is done in a development or staging environment, and once changes pass your team's quality assurance, they are deployed to staging or production as desired.

This article describes two different methods of setting up a workflow among multiple instances, depending on whether you have:

Looker recommends using a single repository whenever possible.
 

Setup with a Single Repository and Pull Requests


First, we'll describe how to setup an environment that has multiple Looker instances (development, staging, and production, for example) with pull requests enabled.

This option is currently only available if you are hosting your Git repository.
Starting in Looker 7.12, the following actions are available on the Configuration tab of the Project Settings page. Navigate to the Project Settings page by clicking the Settings icon from the navigation bar.


Pull requests are configured on the Project Settings page, found on the drop-down menu in the LookML section:

936b52e1-404a-43d3-9bbb-b6e8c4cc1977.png

This will open the Project Settings page, where you can select either Pull Requests Recommended or Pull Requests Required:

f5dcf51b-caa1-4b8f-bf6f-a7238e3f2ba1.png


Next, create the trigger on the webhook, as shown below in Git interface:

1550b3b1-62d4-4940-9b4a-1f605b51a230.png

This configuration will allow the lead developer to approve pull requests from the Git web interface, where the webhook will push changes to production.

Starting in Looker 5.20, you can add a secret for your deploy webhook. See our documentation for more information.

You can create a second release webhook to trigger an update to production, manually deploy to production by going to the webhook URL when you're ready to deploy, or base your trigger to production on available Github events.

e63daa4a-db52-481b-9730-701c128af498.png
Comments
markus_zhang
Participant I

I’m sorry but this article seems to be incomplete. There are important issues not discusses:

  • What is the promotion flow? Should we promote as feature->dev->stg->prod, or feature->dev, then feature->stg and feature->prod?
  • There is even no mention of feature branch so I assume your model requires developers to work in dev env directly. However this is not desirable. Just imagine, with a team of a few dozens of BI developers, the dev branch is going to be volatile and all kinds of garbage goes to the bottom. How can they merge into prod or even staging? I hope I misunderstood.
Version history
Last update:
‎06-22-2022 03:35 PM
Updated by: