NOTE
StrongLoop Arc and slc are no longer under active development, and will soon be deprecated. Arc's features are being included in the IBM API Connect Developer Toolkit: Please use it instead.
Skip to end of metadata
Go to start of metadata
Icon

To commit a build to a Git repository, you must have Git 1.7.9 or later.


Building an application:

  1. Install dependencies
  2. Bundle dependencies
  3. Create deploy package, either:

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 --onto option.

Icon

It may be useful to have several different package repositories, for example to manage public and internal releases.  See Using multiple package registries for more information.

Using slc build

Committing a build to a Git repository enables you to track deployment states. For example:

The --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.

Next: Deploy your application to a system running StrongLoop Process Manager; see Deploying applications with slc.

  • No labels