Looker will not be updating this content, nor guarantees that everything is up-to-date.
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.
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:
[1] Development > Production
[2] 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 [1] based on an existing single Looker project, looker_project
, it could easily be adapted for [2] or any number of intermediate hosts between Development and Production as needed.
The general process is as follows:
dev
and prod
.dev
, perhaps on a server owned by the approver. Add the prod
GitHub repo as a second remote: git remote add production <<ssh_url>>
prod
Looker to sync with GitHub as new code is pushed. In essence, set up a webhook on a push
event to notify the Production Looker instance.To designate the existing dev
repo and set up a prod
repo on a second host, follow these steps:
master
is set as the default branch. If a different branch is set as default, change the default to master
. looker_project
: mkdir ~/Desktop/looker_project
cd ~/Desktop/looker_project
git clone git@github.com:MyOrgNameInGithub/looker_project.git
master
branch: cd looker_project
git checkout master
origin
as 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_prod
to house our prod
project:
git remote add prod git@github.com:MyOrgName/looker_project_prod.git
In this case, prod
is 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
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
. In the GitHub UI, we should see that the cloned LookML has been pushed to our new project on the master
branch.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_prod
in 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.
prod
repo 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: [instance_name.looker.com]/webhooks/projects/[project name]/deploy
For example: https://instance_name.looker.com/webhooks/projects/looker_project_prod/deploy
This will cause the Looker host to pull the master
branch 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 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 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.
dev
Looker instance, and all code is committed and deployed via the Looker UI. This pushes the LookML to the master
branch of the development repo.master
, per the instructions on the Setting Up Version Control documentation page.dev
repo to the prod
repo, we just need to run the following in the cloned repo (while on the master branch): git pull
git push prod master
prod
repo detects the push, GitHub will hit the deploy webhook on the Looker prod
instance to pull in these changes.