The CI/CD and DevOps Blog

Using NPM Private Modules In Your CI Workflow

In addition to publicly available packages, npm also allows users to publish and manage packages in a private namespace. If you want your npm install command in the CI workflow to install your private dependencies, there are a couple of setup steps that are required.

Unless you follow these steps, your npm install command will throw an error, such as 

  npm ERR! 404 Not found : @manishas/my-private-module   

 

Step 1: Get your npm auth token

First, you need to find your npm token, which is stored in the .npmrc file in your home directory. The file will contain a line which looks like this:

  //registry.npmjs.org/:_authToken=GFYR$E8D-89DG-GH54-HJDR-TYDGOSYT785T  

Copy the value of the token, which is everything after authToken=

CI For Gitflow Or Feature Branch Workflows

Many Shippable customers create branches on their source control repository in order to work on new features.

Let's take an example of two developers, Ted and Mary,  who're going to work on Feature #42 for the FooApp application. Their feature branch workflow will look something like this:

  1. Ted creates a feature branch off the master branch. He calls the new branch feature-42
  2. Ted and Mary commit code changes to feature-42
  3. When coding for Feature #42 is complete, Mary sends a pull request to merge feature-42 into master 
  4. A dev lead reviews the pull request.and if everything looks good, merges the code into master
  5. If the merged code passes all checks, feature-42 is deleted

Fig 1: Gitflow workflow

The Atlassian team has written a more detailed description of the feature branch and Gitflow workflow which explains how to handle it from a source control provider perspective: 

Let us look into how you can configure your Continuous Integration (CI) platform to handle these scenarios. In this example, we'll use Shippable's native CI functionality. 

Q&A with Eric Vanderburg - A Cyber Security Expert

We recently had the pleasure of talking to Eric Vanderburg, the cyber security and DevOps expert to understand his viewpoints on DevOps, the digital transformation of workforces and legacy systems to cloud and community-based models. 

The Difference Between CI Pipelines and DevOps Assembly Lines

What's in a name? wrote the greatest Bard that ever lived.

He was wrong. If someone ever asked me a hypothetical question about which dead person I'd want to have a conversation with, it'll definitely be Shakespeare. Let me explain why.

When we launched Shippable Pipelines last year, we wanted to highlight the difference between plain vanilla CI and the capability to put together a deployment "pipeline" that spans orchestration across multiple environments and supports all tasks involved in software delivery like CI, infrastructure provisioning, test automation, deployments, security patching, release management, config mgmt, service discovery, etc. 

However, shortly after we launched, other CI providers launched their own interpretations of "pipelines"! For example,

How did everyone come to the same exact place so rapidly? As we found out, they didn't. Pipelines was being used as a fancy name for CI, with features that Shippable had supported for over two years, like Matrix builds for splitting tests or testing against multiple environments for example. 

We needed a way to explain why Shippable is different. This blog explains why we landed on DevOps Assembly Lines as the perfect way to describe our approach to DevOps and CI/CD. 

Q&A with Adrian Mouat, author Of 'Using Docker'

Our very own Pavan Belagatti recently chatted with Adrian Mouat, the author of Using Docker. Read on about what he has to say about the book, the future of Docker, and DevOps...
 
 
[Pavan] Hey Adrian, thanks for taking the time to chat with us. Can you introduce yourself to our audience?
[Adrian] I work for a company called Container Solutions whose mission help companies transition to the new "cloud native" world of containers, orchestrators and microservices. My title is "Chief Scientist" which means I'm responsible for investigating and developing software designed to help companies adopting cloud native. A lot of my time is also taken up providing training and speaking about cloud native technologies such as Docker.
 
[Pavan] When did you become passionate about Docker? What is the story behind it?
[Adrian] At a previous company, we started using Docker and running a Docker meetup, where we realised its huge potential. It enabled us to rapidly iterate on a few projects we were playing with, which would have taken far longer with VMs or other approaches.