ALM strategy for component library

(0) Share

Report

Posted on by thomass19

Hi all,

I'm trying to figure out what the best practices are to share and maintain component libraries across a tenant.

What I would ideally like to achieve is the following:

Create a component library that all users in my tenant can access so they can use the components in their apps. Whenever I make a change to the original component library, I want all apps that make use of the component library to be prompted to update to the latest version.

What I'm struggling with in particular, is what setup would be needed to make this work across multiple environments. In MSFT documentation I only find reference to sharing and maintaining components libraries within the same environment. Is there a way to share component libraries on tenant level?

To illustrate (simplified):

1. Environment A (DEV): Original component library (Unmanaged Solution)

2. Environment B (PRD): Original component library (Managed Solution) -> All users have access to this environment

3. Environment C (DEV): User imports the CL from step 2 in his development environment + uses components in app

4. Environment D (PRD): User deploys app (and CL) to production environment

When I make changes to the component library and deploy a new version to environment B, is there a way to (soft) push these changes to all environments (C and D) in which there is an instance of my component library?

Many thanks in advance!

Categories:

Governance & administering

I have the same question (0)

All responses (2)

Answers (1)

Verified answer

joe_hannes_col 1,843 Super User 2024 Season 1 on at

Like (1)

Report
Hello @thomass19,

Yes, it is possible to develop a component library in one environment and then to push/import it to other environments.
Generally, you would have one environment in which you develop the solution as unmanaged (env A in your example above), and multiple environments in which you consume the managed solution (envs B, C, D...).
Depending on your level of expertise and the frequency with which you update the solutions, you have two options:
Manually import the solution as managed from env A and import it manually into envs B, C, D
Set up pipelines that will
Export the unmanaged solution from env A, optionally committing it (as managed and unmanaged solutions) to a Azure Git repo, for example
Import the managed solution exported from env A into any other environments you define, e.g. B, C, and D
I'm guessing you are quite familiar with unmanaged and managed solutions, but if you want to read up, here is a link.
If you want to automate the ALM process (highly recommended), you have multiple options:
Build your own pipelines, e.g. using DevOps
Use the ALM Accelerator from the Center of Excellence
If you are using Managed Environments, use the built-in ALM capabilities (currently in Preview)
Referencing the solution from envs C and D that you imported into env B is not possible - you would have to import the managed solution into every environment where you want to use the components.

Was this reply helpful? Yes No
thomass19 4 on at

Like (0)

Report

Thank you very much for the clear and informative answer! This is exactly what I was looking for.

Was this reply helpful? Yes No