Tag Archives: Continuous Deployment


This is a multi-part documentation of how to setup a CI/CD workflow in AWS. Some of the tools that will be used are EC2, Chef, CloudFormation, Jenkins, Rspec, and Apache. If you have questions feel free to leave a comment or track me down on Twitter at @devopshomelab Part 1 – Workstation Setup – The […]


Jenkins to Nexus with Git Polling

via Jenkins to Nexus with Git Polling – Tech Tip #76 – Miles to go 2.0 ….

Build Binaries Only Once is a very important principle of Continuous Deployment (CD). However that blog guides you to build and deploy binaries to Nexus from your development machine. This is fine as a starting step where everything is locally contained on your laptop and you are just testing setup to figure out how things work. But everybody in the team having a local Nexus repository defies the purpose of a “shared repository”.  This is also against Continuous Integration (CI) where the source code committed by different team members checked out and build on a CI server. And CI is a fundamental requirement for Continuous Deployment. How do you set this up then?

You use a CI server to push binaries to Nexus.

There are a varety of CI servers in both open source and commercial range. Jenkins, Travis,  CruiseControl and Go are some of the popular ones in the open source land. They all have a commercial edition as well. Bamboo and AnthillPro are a couple of popular commercial-only offerings. This blog will use the simplest, most popular, and easiest to use Jenkins CI server.

Build Binaries Only Once for Continuous Deployment

via Build Binaries Only Once for Continuous Deployment – Miles to go 2.0 ….

One of the fundamental principle of Continuous Delivery is Build Binaries Only Once, or in short BBOO. This means that the binary artifacts should be build once, and only once. These artifacts should then be stored in a repository manager, such as a Nexus Repository. Subsequent deploy, test, and release cycles should never attempt to build this binary again and instead reuse this binary. This ensures that the exact same binary has gone through all different test cycles and delivered to the customer.

Several times binaries are rebuilt during each testing phase using a specific tag of the workspace, and considered the same. But that is still different! This might turn out to be the same but that’s more incidental. Its more likely not same because of different environment configurations. For example, development team might be using JDK 8 on their machine and the test/staging might be using JDK 7. There are a multitude reasons because of which the binary artifacts could differ. So it’s very essential to build binaries only once, store them in a repository, and make them go through different test, staging, and production cycle. This increases the overall confidence level of delivery to the customer.

Continuous Deployment for iOS

Updating your iOS app should not be painful and time consuming. Automate the whole process to start with Continuous Deployment. Original Post>>