Deploying micro frontends to different clusters from a single repository

1. A computer-implemented method comprising:

receiving, by a user interface (UI) deployment service instance running in a runtime cluster, a module name and module hash of a UI module to deploy, wherein the module hash corresponds to a UI bundle file name of a UI bundle file that includes build output from building the UI module;

using the module name and module hash to update a shell service database used by a shell service serving applications for the runtime cluster, wherein updating the shell service database includes updating a module hash stored in the shell database for the UI module;

generating a manifest for the runtime cluster, using the updated shell service database;

determining, by the UI deployment service instance, that the UI deployment service instance is running in the runtime cluster;

storing, in a manifest repository, in a cluster-specific folder corresponding to the runtime cluster, the manifest for the runtime cluster, wherein the manifest repository stores manifests for other versions of the UI module in other folders of the manifest repository corresponding to at least one other runtime cluster; and

updating a manifest location value in the shell service database to refer to the cluster- specific folder, to enable the shell service, in response to an application request to load the UI module, to access the manifest for the runtime cluster to determine the UI bundle file name for loading the UI bundle file when loading the UI module.

2. The computer-implemented method of claim 1 , wherein different instances of the same UI deployment service run in different runtime clusters.

3. The computer-implemented method of claim 1 , wherein the different runtime clusters include development, staging, pre-production, and production clusters.

4. The computer-implemented method of claim 3 , wherein the other versions of the UI module include at least one of a first version of the UI module for the production cluster, a second version of the UI module for the pre-production cluster, a third version of the UI module for the staging cluster, and a fourth version of the UI module for the development cluster, where each of the first, second, third, and fourth versions are different versions of the UI module.

5. The computer-implemented method of claim 1 , wherein different UI deployment service instances of a same UI deployment service are used for different UI modules.

6. The computer-implemented method of claim 1 , wherein the UI deployment service instance receives the module name and the module hash from a deployment pipeline.

7. The computer-implemented method of claim 1 , wherein the deployment pipeline is invoked after a build process.

8. The computer-implemented method of claim 1 , wherein the build process generates the module hash using contents of the UI module.

9. The computer-implemented method of claim 1 , wherein code for the UI module is stored with code for other UI modules in a single code repository.

10. The computer-implemented method of claim 1 , wherein the manifest repository stores manifests for other UI modules other than the UI module.

11. A non-transitory, computer-readable medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations comprising:

receiving, by a user interface (UI) deployment service instance running in a runtime cluster, a module name and module hash of a UI module to deploy, wherein the module hash corresponds to a UI bundle file name of a UI bundle file that includes build output from building the UI module;

using the module name and module hash to update a shell service database used by a shell service serving applications for the runtime cluster, wherein updating the shell service database includes updating a module hash stored in the shell database for the UI module;

generating a manifest for the runtime cluster, using the updated shell service database;

determining, by the UI deployment service instance, that the UI deployment service instance is running in the runtime cluster;

storing, in a manifest repository, in a cluster-specific folder corresponding to the runtime cluster, the manifest for the runtime cluster, wherein the manifest repository stores manifests for other versions of the UI module in other folders of the manifest repository corresponding to at least one other runtime cluster;

updating a manifest location value in the shell service database to refer to the cluster- specific folder, to enable the shell service, in response to an application request to load the UI module, to access the manifest for the runtime cluster to determine the UI bundle file name for loading the UI bundle file when loading the UI module.

12. The computer-readable medium of claim 11 , wherein different instances of the same UI deployment service run in different runtime clusters.

13. The computer-readable medium of claim 11 , wherein the different runtime clusters include development, staging, pre-production, and production clusters.

14. The computer-readable medium of claim 11 , wherein different UI deployment service instances of a same UI deployment service are used for different UI modules.

15. The computer-readable medium of claim 11 , wherein the UI deployment service instance receives the module name and the module hash from a deployment pipeline.

16. A system comprising:

a computing device; and

a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device, cause the computing device to perform operations, the operations comprising:

receiving, by a user interface (UI) deployment service instance running in a runtime cluster, a module name and module hash of a UI module to deploy, wherein the module hash corresponds to a UI bundle file name of a UI bundle file that includes build output from building the UI module;

using the module name and module hash to update a shell service database used by a shell service serving applications for the runtime cluster, wherein updating the shell service database includes updating a module hash stored in the shell database for the UI module;

generating a manifest for the runtime cluster, using the updated shell service database;

determining, by the UI deployment service instance, that the UI deployment service instance is running in the runtime cluster;

storing, in a manifest repository, in a cluster-specific folder corresponding to the runtime cluster, the manifest for the runtime cluster, wherein the manifest repository stores manifests for other versions of the UI module in other folders of the manifest repository corresponding to at least one other runtime cluster;

updating a manifest location value in the shell service database to refer to the cluster-specific folder, to enable the shell service, in response to an application request to load the UI module, to access the manifest for the runtime cluster to determine the UI bundle file name for loading the UI bundle file when loading the UI module.

17. The system of claim 16 , wherein different instances of the same UI deployment service run in different runtime clusters.

18. The system of claim 16 , wherein the different runtime clusters include development, staging, pre-production, and production clusters.

19. The system of claim 16 , wherein different UI deployment service instances of a same UI deployment service are used for different UI modules.

20. The system of claim 16 , wherein the UI deployment service instance receives the module name and the module hash from a deployment pipeline.