Git promotion using a Single Looker environment (Community)

View the original community article here

Last tested: Jan 28, 2020
 

Some users are, for one reason or another, limited to using a single Looker instance for dev > prod but have the need for set up a promotion workflow to do testing against different database environments or different application environments. While we recommend setting up additional Looker instances to support this type of workflow, it is possible to set up a dev workflow within a single Looker instance. These are our recommendations for setting up this workflow within a single Looker instance.

1. Assuming we have 3 database environments to test against, set up 3 connections (one for each database) in Admin > Connections.
2. Create a separate git repository for each combination of your Project + workflow step. In example above, we would have 3 Projects and 3 git repos. During git promotion, use git script to update connection parameter and model names. Looker does not allow you to use the same model name more than once in the same Looker instance. See link for git script guidance: https://help.looker.com/hc/en-us/articles/360002110227-Git-Workflow-Using-Multiple-Repositories-Across-Multiple-Instances-Development-Staging-and-Production
3. Only use LookML dashboards for canned/managed reports.
4. If adding links to other LookML dashboards in dimensions, use model._name instead of hardcoded model name to reference lookml dashboards path. (ie: /dashboards/{{ model._name }}::mydashboard)

Word of caution with this approach is that if something you're doing in "dev" crashes the instance, then "prod" goes down as well as this is a single Looker instance.

Additional Suggestions:
(1) Separate the workflow between code vs content
(2) Consider using dashboard slugs (Why? For example, dev content might be dashboard id 10 but QA content will be a different number, and prod will be the same issue). You will need to manually/programmatically make the links the same across all 3
(3) Create a project manifest file. Another way to get around to different connections is to use constants in the connection name in the model. For example, if you have 5 models in the project, use a constant to define the connection name and just edit the manifest file when moving the code from dev to qa project.
(4) For Looker content management you can check out Gazer, a command line tool.

Additional information can be found here and here