October 15, 2024 at 8:09 am
Hey all,
Just wondering how do you guys / girls set up git repo(s) for those things mentioned in the title esp. for those which use Azure DevOps (and has CI/CD set up).
Do you set up only one repo in a project in Azure DevOps, and within that repo, the objects are placed in separate folders based on their types, eg. a folder for SQL database objects/projects, a folder for SSIS packages/integration solution, etc?
Or is it better to create a separate repo for each object type?
Does it matter / have implications, esp, for configuring CI/CD in the future?
Also, how do you source control Power BI files? I am thinking to only source control the template file (pbit) as it's much smaller in size if it's import mode, then put it in git also. However, that means each time I want to deploy the dashboard, I need to save it as pbix file - creating an additional step. Would that work or comply to best practice?
I would like to hear your thoughts and experience on this. Thanks
October 15, 2024 at 8:31 am
Different people will do things in different ways, as it depends on how you want to work together, how many developers there are and how many projects there are.
I work in a small team and we separate repos by type: database, SSIS etc.
Power BI is gradually evolving into something which can be nicely source controlled, but it's not the best experience.
For semantic models, I use PBIPs (Power BI Projects) which can be saved in TMDL format, which work quite nicely with VCSs.
PBI reports can also be saved in PBIP format (and not as PBIXs), but I don't have much experience of this.
Within Power BI, I have Dev, QA and Prod workspaces set up for each area. The Dev workspace is connected to Git (while QA and prod are not). I use deployment pipelines to move workspace objects from Dev to QA to Production.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 15, 2024 at 3:41 pm
There isn't a single true path through this.
Generally, a database gets one storage location. Depending on the tools I'm using (I work for Redgate, so Flyway is the tool of choice, but I've used others), I let the tool drive folder creating within the storage location. Probably that means tables in one spot, procedures in another, and so on. Generally speaking, SSIS went to a different location, as did SSRS. Especially since SSRS was managed by a different team on a different schedule.
I've seen all sorts of different mechanisms here. Generally, it's driven by the tools you're using to do the actual database deployments.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply