By setting up a Git workflow across multiple Looker host instances, you can create a dedicated development environment for developers whilst preventing other users from coming into contact with experimental code. All development and code review is done in a development or staging instance. Once changes pass your team's quality assurance review, they are deployed to a staging or production instance as desired.
This article describes the method for setting up a workflow among multiple instances and multiple Git repositories. If you have multiple instances and one Git repository, see the Git Workflow Using One Repository Across Multiple Instances — Development, Staging, and Production Help Center article.
Looker recommends using a single repository whenever possible.
Advanced Git Setup for Multiple Repositories
This setup requires multiple Git repositories and some knowledge of Git commands. If you have questions about how to set up this workflow, please contact Looker support.
You may want to set up multiple Looker hosts to achieve a development workflow that looks something like:
 Development > Production
 Development > Staging > Production
Each of these stages resides on a dedicated Looker host instance. This configuration uses a manual Git process to move code between two separate GitHub repos that can be automated or kicked off by a button.
Although this method shows a development workflow configuration  based on an existing single Looker project,
looker_project, it could easily be adapted for  or any number of intermediate hosts between Development and Production as needed.
The general process is as follows:
- Create two GitHub repos,
- Associate each repo with their respective Looker instances, Development and Production, according to the Setting Up and Testing a Git Connection documentation.
- Create a local Git repo that is a clone of
dev, perhaps on a server owned by the approver. Add the
prodGitHub repo as a second remote:
git remote add production <<ssh_url>>
- Create a webhook trigger in the production GitHub repo to notify
prodLooker to sync with GitHub as new code is pushed. In essence, set up a webhook on a
pushevent to notify the Production Looker instance.
- Implement some kind of quality control around the second item in the migration process shown above, based on what works best for your team.
To designate the existing
devrepo and set up a
prod repo on a second host, follow these steps:
- In the Github UI, go to the existing project, select Settings, and ensure that
masteris set as the default branch. Update if needed.
- Create a local folder and clone the
mkdir ~/Desktop/looker_project cd ~/Desktop/looker_project git clone email@example.com:MyOrgNameInGithub/looker_project.git
- Switch to the cloned project and make sure you're on the
cd looker_project git checkout master
- If we view the Git remotes for the cloned repo, we should see the
originas the original repo location:
git remote -v
Create a new empty repo via the GitHub UI. For our example, let's name the repo
looker_project_prodto house our
- Add our new empty repo as a new remote for the cloned repo, as below:
git remote add prod firstname.lastname@example.org:MyOrgName/looker_project_prod.gitIn this case,
prodis simply a name we ascribe to the remote; it can be whatever we want. We can check that it was added successfully per the above.
- Perform an initial push to our new remote of the
git checkout masterThis will ensure we're on the correct branch:
git push prod masterThis will push the
masterbranch of our cloned repo to our new remote,
- In the GitHub UI, we should see that the cloned LookML has been pushed to our new project on the
Now, create a new empty project on the Production Looker instance:
Enter Development Mode, select the Develop menu, then Manage LookML Projects:
Create a New LookML project:
Choose a name (like
looker_project_prodin our example) and select Blank Project.
Select Create Project.
Follow Looker Git setup instruction prompts to connect to our new repo. For a complete tutorial, see our Setting Up and Testing a Git Connection documentation.
Add the Looker SSH key to the GitHub project using the UI. Ensure that you provide read/write access initially.
Choose Sync Development Mode when prompted. Looker should pull in the code from the new
prodrepo to the local Looker file system.
Next, configure the new repo via the Github UI to hit Looker's deploy webhook on the production host.
In the GitHub UI, select Settings, then Webhooks, then Add webhook.
Enter the URL in the following format:
This will cause the Looker host to pull the
masterbranch from the Git repo to its local file system, making the changes visible.
Starting in Looker 5.20, you can add a secret for your deploy webhook.
Once configured per the above, we can reset the Git connection using the Looker UI on the
In the Github UI, we can make the SSH key read-only for the
prod repo by not selecting Allow write access, so that no development can happen on the Production instance.
This means that any user entering Development Mode (including during setup) will see the error below while syncing their Development Mode. This, in effect, is what we want.
Proposed Development Workflow
- LookML development takes place on the
devLooker instance, and all code is committed and deployed via the Looker UI. This pushes the LookML to the
masterbranch of the development repo.
- We can enable pull requests to allow for code review before commits are merged into
masterper the instructions on the Setting Up Version Control documentation page.
- To move LookML from the
devrepo to the
prodrepo, we just need to run the following in the cloned repo (while on the master branch):
git pull git push prod master
- When the
prodrepo detects the push, GitHub will hit the deploy webhook on the Looker
prodinstance to pull in these changes.