Through the course of Power BI report development, it's important that we consider a best practice method for how reports will be developed and deployed to business users. A development lifecycle is the iterative process around creating and deploying Power BI content. These are generally categorized into steps, where each step encompasses certain attributes as the report is matured and refined. Let's take a closer look at each of these three steps.

The first step in report creation is the development step. Here, a report is created, likely in Power BI Desktop, and deployed to a development workspace. This workspace exists as the first landing zone for new Power BI content, where workspace users can collaborate on building and refining the report. Once content has been finalized, it's moved into the second step of the lifecycle, which is called the test phase. Here, the report will be migrated to a new workspace and likely deployed in an app, where a small group of users will review, test, and provide feedback on the content.

In many cases, as reports move from development to tests, the data sources are also updated accordingly to a test database, if one exists. The final step in the report development lifecycle is the production step. This is where the report is moved to a production workspace and deployed to business users in a production workspace app. This represents the highly consumable content we wish our business users to digest. As we gather feedback from them, we will continuously move the report through this lifecycle again as changes are developed, tested, and deployed.

A question that often comes up during lifecycle discussions is around version control of Power BI projects. In the previous slides, we demonstrated how a Power BI report would exist in three different workspaces at the same time. But what happens to the original report once changes are made? This is the idea of version control. And unfortunately, Power BI has no native system for managing each version of the same Power BI report. If we save the Power BI desktop file to OneDrive or SharePoint, we can use the standard version control that exists in those programs.

Alternatively, we can save Power BI reports to the service with different names, although this is not as elegant and efficient. Efforts are underway to amend this in the Power BI service. As mentioned in previous lectures, workspaces should be considered for development activities only. Generally, only report creators and testers should be invited to these spaces. As reports move through the lifecycle, they will be deployed to business users via a workspace app. These should always be considered the final destination for consumable Power BI content.