In Bit, everything is a component. The app is also just a deployable component.
This means we can easily compose it with another component - the Netlify Deployer component - to deploy it to Netlify. Just like playing with Lego blocks.
As you can see in the above code snippet, we are defining two site names. A production one and a staging one. When you lock your component to a release version (e.g. 1.0.0), the production site name will be used, whereas the staging site name will be used for snaps with no release version (hashes).
Now all we have to do is to run the bit tag command to deploy the app to Netlify:
$bittag--message"first version & deploy"
Since all components in the workspace are new, Bit will tag them all and deploy the app to Netlify. Here is the terminal output:
newcomponents(first version for components)> firstname.lastname@example.org> email@example.com> firstname.lastname@example.org
If you look closely at the output, you will see that the deploy_application task was executed. This is the task that deploys the app to Netlify:
✔ env "teambit.harmony/aspect", task "teambit.harmony/application:deploy_application" has completed successfully in 8s
Because we built our app based on component-based software engineering (CBSE) principles, each part of the app functions independently and can be exported to a remote scope, imported into a different workspace, and used in another app as a dependency
Incremental updates and deployment
Let's say we want to modify the home page. we'll make a simple change in the home.tsx file:
It would be expected that only the pages/home component would be versioned if we tagged again. However, this is not the case. All home page dependents (in this case only the app) will be tagged in the workspace, and the app will be deployed again. The reason is that Bit tracks the dependency graph, and knows which components are impacted.
$bittag--message"update home page"
Here's the output:
changed components(components that got a version bump)> email@example.com auto-tagged dependents: firstname.lastname@example.org
The app was automatically tagged, which is exactly what we wanted. When we make changes, only the affected components will be tagged and deployed. As a result, we can save a lot of time and resources.
Don't forget to export the second version of the apps/my-app and pages/home components to the remote scope:
A glimpse into the (near) future
Here's a sneak peek at a new product released on bit.cloud later this year called Ripple CI - the first component-driven continuous integration tool.
With Ripple, you only build components, not projects. When you update a component, Ripple will run for that component and every dependent component impacted by the change, across your entire system and apps.
As a result, your builds run much faster. They propagate to every impacted product and simulate the change. In addition, they will save tons of time by isolating failures and errors, so you don't have to run everything again. It's still in beta for now :)
In the picture above from Ripple-CI, you can see changes were made to the use-change-request hook. Consequently, only dependent components are rebuilt and versioned until the app component is deployed (if all tests and builds pass).
We learned how to deploy a React app to Netlify using Bit in this blog post. Additionally, we learned how to keep the app up-to-date by only tagging the affected components.
Everything becomes easier when you build apps in a distributed (component-driven) manner. Components can be built, tested, and deployed independently. After that, you compose them together to build more apps and features, just like you would with Lego blocks.
Changing the deployer component would allow us to change the service provider anytime. The deployment pipeline could also be expanded with more deployers. It's as simple as adding a new component to the pipeline, for example, the Cloudflare Deployer.
There is still a lot to learn about component-based software engineering. Please visit the Documentation for more information. Feel free to join the community Slack channel if you have any questions.
I have now implemented the option to have two site names, one for production and one for staging. When you lock your component to a release version (e.g. 1.0.0), the production site name will be used, whereas the staging site name will be used for snaps with no release version (hashes).
As a result, every app with the Netlify deployer component as a dependency (such as The Bit Blog you are currently reading) will have the same, updated, deployment pipeline. An excellent example of how Bit can help you build a component-based software engineering system.