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 in this article)
- Multiple instances and multiple repositories (explained in Git Workflow Using Multiple Repositories Across Multiple Instances—Development, Staging, and Production)
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.
Pull requests are configured on the Project Settings page, found on the drop-down menu in the LookML section:
This will open the Project Settings page, 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.