Solved: Single instance of Looker supporting Dev/QA/UAT - Page 2

Audy · 05-17-2024 01:08 AM

Hi All,

We have been struggling with setting up Dev/QA/UAT environments on a single instance of Looker.

Our core issue is around LookML - Git integration where it is too open to all users (access to multiple branches and operations) so setting up controls in terms of QA/UAT users only accessing specific read-only branch is something we do not have a solution for.

Secondly, we are using manifest.lkml to enable variables for gcp project, data connection, bigquery dataset but are struggling to find a way to embed that into git promotion where in we need to modify variable values to reflect QA or UAT values.

Any thoughts are really appreciated guys!

David-Google

Hey there Audy,

Great use case and question! With regards to the issues surrounding the LookML<>Git integration, there should be controls on the Looker side that can help Admins distribute the correct level of access to all kinds of users. If you take a look at our permissions list doc, you can see that we have 3 "levels" of permissions for developers. The lowest level of permissions is `see_lookml` which enables folks to view the LookML behind the scenes, but they won't have the ability to toggle on development mode and adjust any code. The next level up would be `develop` which enables users to change the LookML code locally in their dev branch, with the final tier of access being `deploy` which enables developers to push their changes to production. Additionally, if you can use multiple account HTTPS git connections on your git repositories, that can help control access and permissions on the repository side as well. Because users are providing their own git user account information on a per-user basis, we can control which accounts have access to varying permissions on the repository from outside of Looker as well.

Regarding the manifest.lkml file you mentioned, would it be feasible to use parameterized connections in the Admin -> Connections panel? At a high level, user attributes can be used in database connections and I'm thinking it may be easier to assign dev/QA/prod attribute values than to update an ephemeral LookML file under the hood. Worst case scenario--if the manifest file is a hard requirement for this use case--it may be possible to use a tool like PyLookML to programmatically update the values within your manifest file to QA/UAT values as well.

Let me know if that ends up working out for you!

Best,

David

View solution in original post