Use the slc build command to commit builds into a Git repository. Doing this enables you to track and version product deployments. Doing this manually commits both build products and dependencies (
node_modules) to Git, pollutes source branches, creates massive Git commits, and huge churn on development branches and repositories.
In contrast, using
slc build --commit commits an exact replica of current branch source and build products onto a deployment branch. After the commit, the deployment branch tip shows as a merge of the deployment and source branches. This enables you to keep a complete history of deployment builds in Git, separate from development branches. You can push deployment branches to the same repository as the development branches if you wish.
You can also push branches prepared like this to cloud platforms such as Bluemix or Amazon.
The default name of the deployment branch is "deploy". You can configure it with the
Using slc build
Committing a build to a Git repository enables you to track deployment states. For example:
--commit --onto deploy options specify to commit the build to the "deploy" branch. The
--install option commits the dependencies (the node_modules directory) to the specified branch ("deploy").
For example, in your repository root directory, perform this one-time setup:
Typically, a repository will have a "master" branch where developers commit work regularly and a "production" branch, for specific changes that have been tested individually (or collectively, depending on your development practices). You then test the "production" branch in the same configuration and environment as your production environment. The idea is that the "production" branch should always be a candidate for deployment.
Finally, you build the "production" branch onto the "deploy" branch as follows:
These commands checkout the "production" branch and then build it to the "deploy" branch, which is then actually deployed.
See slc build for more information.