Pipelines de despliegue independientes

Welcome! In traditional applications, deploying changes often means deploying the entire system. This can be slow and risky.

Micro Frontends aim to solve this by breaking down the frontend into smaller, independent parts. This lesson focuses on how each part can be deployed on its own.

An independent deployment pipeline means each Micro Frontend (MFE) has its own dedicated automated workflow for building, testing, and deploying.

• Each MFE acts like a mini-application.
• It doesn't wait for other MFEs.
• It has its own version control and release cycle.

Adopting independent pipelines brings significant advantages:

• Faster Releases: Teams can deploy their MFE's updates without coordinating with other teams.
• Reduced Risk: A deployment issue in one MFE doesn't necessarily block or break others.
• Team Autonomy: Teams own their MFE end-to-end, from development to deployment.

In an independent pipeline, each MFE is built in isolation. This means:

• Its code is compiled or transpiled.
• Dependencies specific to that MFE are bundled.
• It produces a self-contained deployment artifact (e.g., a JavaScript bundle, static assets).

This artifact is then ready for testing and deployment.

Testing is also independent. Each MFE's pipeline includes its own set of tests:

• Unit Tests: Verify small parts of the code.
• Integration Tests: Check how internal components work together.
• Contract Tests: Ensure the MFE adheres to agreements with other services or MFEs it interacts with.

These tests run before deployment to ensure quality.

Once an MFE's artifact is built and tested, it's deployed to a hosting environment. Common choices include:

• Content Delivery Networks (CDNs)
• Cloud storage services (e.g., AWS S3, Google Cloud Storage)
• Static file servers

The host application then loads these independently deployed MFEs at runtime, often using technologies like Webpack Module Federation.

A key goal is to avoid a single point of failure. If one MFE's deployment fails, it should not bring down the entire application or prevent other MFEs from deploying.

This requires careful design of your pipelines and runtime error handling (which we cover in other lessons!).

Each MFE typically lives in its own repository (polyrepo) or a dedicated folder within a monorepo. This allows:

• Independent versioning of each MFE.
• Teams to choose their own release cadence.
• Features for one MFE to be released quickly, without waiting for others.

Many popular CI/CD tools can be configured to support independent MFE pipelines:

• GitHub Actions: Define workflows per repository or path.
• GitLab CI/CD: Use .gitlab-ci.yml in each MFE's repo.
• Jenkins: Set up separate jobs or use Jenkinsfiles for each MFE.
• CircleCI / Travis CI: Similar configurations for project-specific pipelines.

The key is to define a pipeline that triggers only for changes relevant to a specific MFE.

Which of the following is NOT a primary benefit of using independent deployment pipelines for Micro Frontends?

Today, we explored the power of independent deployment pipelines for Micro Frontends.

• Each MFE gets its own build, test, and deploy workflow.
• This leads to faster releases, reduced risk, and greater team autonomy.
• MFEs produce isolated artifacts and are deployed to hosting environments like CDNs.

This independence is crucial for scaling development in large-scale applications!