Continuous Distribution and Deployment

In previous post, we discussed about Continuous Integration, its evolution, CI best practices and the advantages it offers to the developer community as well as to the consumers. In this part, we will discuss Continuous Distribution and Deployment.

Continuous distribution (a.k.a. delivery) can be defined as a practice of keeping code base deployable at any point by making sure application passes all automated tests and is ready to push into production or making package available for developers to download.

 


Once the production build is done and tested, the artifacts are ready for deployment. In case where the end product is a package (e.g. a tar archive or an executable), it is uploaded to a public repository where all stakeholders can then obtain it from that repository.

In cloud computing scenario, the end product could be a service which can be deployed to cloud. These services then can be consumed by others.

How to deliver these artifacts, how to deploy them, where to deliver/deploy is specified by adding a few more steps to the CI pipeline.

Continuous deployment is closely related to CI and is an extension to the existing CI. Most of the existing CI engines do provide some sort of deployment facility as well. It deals with automatic release of application to test or production environment (a.k.a. "push button deployment").

Continuous delivery ensures that the code checked in on the main branch is always deployable thereby reducing time to market. It facilitates a shorter user feedback loop which in turn ensures that the right product is made available all the time.

Continuous delivery improves productivity and higher efficiency due to shorter deployment cycles and less time spent on debugging. This also ensures reliable releases of higher quality.

We will discuss about CI engines in the next part.

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona
Read more

Common Git Tips

Image
Obtain list of commits git reflog --oneline git log --oneline These commands will also print commit ID - a.k.a. commit hash. Obtain list of branches created by a user git for-each-ref --format=' %(authorname) %09 %(refname)' --sort=authorname | grep <username> Obtain branch hash git show-ref branch_name Delete a local/remote branch Assume that a branch "bugfix/114355" is created to fix a bug. To delete the local branch: git branch -d bugfix/114355 git branch -D bugfix/114355 '-D' is same as specifying "--delete --force" . To remove the remote branch as well: git push origin --delete bugfix/114355 Undo last commit git reset --soft HEAD~1 Roll back repo to a commit To roll-back the repository to a particular commit, follow these steps. find the hash corresponding to the particular commit by checking the commit logs: git log --oneline roll back the repository by resetting the HEAD pointer: git reset --hard <commit_hash> Remove the latest co
Read more