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:
- Multiple instances and one repository (explained here), or
- Multiple instances and multiple repositories (explained in another article)
Note: Looker recommends using a single repository whenever possible.
Setup with 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.
Please note this option is currently only available if you are hosting your Git repository.
Pull requests are configured from the Project Settings menu found in the LookML section:
This will open the settings screen where you can select either “Pull Requests Recommended” or “Pull Requests Required”:
Next, create the trigger on the webhook as shown below in Git interface:
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.