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 another article)
- Multiple instances and multiple repositories (explained in this article)
Note: 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 setup this workflow, please contact your Customer Success team.
Quite often, we wish 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. This configuration uses two separate GitHub repos and a manual Git process to move code between them (which can be automated or kicked off by a button).
This will be a practical guide to configuring development workflow , based on an existing single Looker project—we'll refer to this as ‘looker_project.' This method could easily be adapted for  or any number of intermediate hosts between Dev and Production, as needed.
The general process is as follows:
- Create two GitHub repos, dev and prod.
- Associate them to their respective Looker instances, per our documentation.
- Create a local Git repo that is a clone of dev , perhaps on a server owned by the approver. Add the production GitHub repo as a second remote: “git remote add production <<ssh_url>>”
- Create a webhook trigger in the production GitHub repo, to notify prod Looker to sync as and when new code is pushed. In essence, set up webhook on push event, to notify the production Looker instance.
- Implement some kind of control around Item 2 in the migration process above, based on what works best for your team.
Make the existing repo ‘Development' and set up a ‘Production' repo on a second host
1. In the Github UI, go to the existing project > settings, ensure that Master is set as the default branch (and update if needed).
2. Create a local folder and clone the ‘looker_project' repo into this:
mkdir ~/Desktop/looker_project cd ~/Desktop/looker_project git clone firstname.lastname@example.org:MyOrgNameInGithub/looker_project.git
3. Switch to the cloned project and ensure we're on the master branch:
cd looker_project git checkout master
4. If we view the Git remotes for the cloned repo, we should see the ‘origin' as the original repo location:
git remote -v
5. Create a new empty repo via the Github UI (let's name this ‘looker_project_prod') to house our ‘Prod' project:
6. Add our new empty repo as a new remote for the cloned repo, i.e. below:
git remote add prod email@example.com:MyOrgName/looker_project_prod.git
Note: ‘prod' is 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.
7. Perform an initial push to our new remote of the master branch:
git checkout master
This will ensure we're on the correct branch:
git push prod master
This will push the master branch of our cloned repo to our new remote, ‘prod.'
8. In the Github UI, we should see the cloned LookML has been pushed to our new project on the master branch.
Create a new empty project on the production Looker instance.
9. Enter Development Mode > Develop > Manage LookML Projects:
Create a New LookML project
10. Choose a name (e.g. ‘looker_project_prod') and select Blank Project:
12. Follow Looker Git setup instruction prompts to connect to our new repo (see our documentation for a complete tutorial).
13. Add the Looker ssh key to the GitHub project via the UI (settings > deploy keys)—ensure that you give read/write access initially.
14. Choose ‘Sync Development Mode' when prompted and Looker should pull in the code from the new prod repo to the local Looker filesystem.
Configure the new repo via the Github UI to hit Looker's ‘deploy' webhook on the production host:
15. Settings > webhooks,
16. Enter the URL in the format: [hostname]/webhooks/projects/[project name]/deploy
This will cause the Looker host to pull the Master branch from the Git repo to its local filesystem (i.e., actually make the changes visible).
Starting in Looker 5.20, you can add a secret for your deploy webhook (see our documentation for more information).
Once configured per the above, we can reset the Git connection (via the Looker UI) on the Prod host:
In the Github UI, we can make the SSH key ‘read' only for the Prod repo, by not selecting
Allow write access, so no development can happen on the ‘prod' host.
Note, this does mean any user entering Dev mode (including while setting up) will see the error below, syncing their developer mode (but, this is in effect what we want).
Proposed Development Workflow
- LookML Development takes place on the Development Looker instance and all code is ‘committed/deployed' via the Looker UI. This pushes the LookML to the Master branch of Development Repo.
- We can enable pull requests for the above, to allow for code review before commits are merged into Master per these instructions.
- To move LookML from the ‘dev' repo to the ‘production' repo (this can be scripted, if wanted), we'd just need to run the following in the cloned repo (when on the master branch:
git pull git push prod master
- When the ‘prod' repo detects to the push, Github will hit the deploy webhook on prod Looker instance to pull in these changes.