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 one or a few developers or administrators greater control over the changes that are deployed to production.
By setting up a Git workflow across multiple Looker host instances, you can create a dedicated development environment for developers while preventing end users from accessing 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 how to set 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 knowledge of Git commands.
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 its respective Looker instances, Development and Production, according to the Setting Up and Testing a Git Connection documentation page.
- 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. If a different branch is set as default, change the default to
- 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
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 assign to the remote; it can be whatever we want. We can verify the remote repo with this command:
git remote -v
- 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,
prod. 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:
On the LookML Project page, click New LookML Project.
Choose a name (such as
looker_project_prodin our example), and select Blank Project.
Click Create Project.
Follow Looker Git setup instruction prompts to connect to the new repo. For a complete tutorial, see the Setting Up and Testing a Git Connection documentation page. Ensure that you provide the deploy key read/write access.
- Follow the prompts in the Looker IDE to deploy to production. Looker will 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.
Once configured per the above, go to your Project Settings page and 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
master, per 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.