Types of CI Engines



The CI engines are available in three flavours: On-premise, Hosted (cloud based) and hybrid CI engines. We'll have a look at each type of CI engine one by one.

On-premise CI Engines


On-premise engines can be deployed on corporate servers. Entire engine and the slaves are within corporate network, protected by firewalls. This type of setup is suitable for large corporations or security-obsessed institutions.

Advantages: Being deployed on company servers, only one time charges for licenses/software need to be paid. It offers options of web interface as well as command line interface. It can work with public as well as private repositories. It also offer complete control over configuration and usage, as per requirements.

Disadvantages: Being in-house, requires provisions for resources, maintenance and upgrades etc.

Hosted CI Engines

Cloud hosted engines are the CI engines provided by third party companies as a service, which provide all the infrastructure to be readily utilized by other entities for building their products. This option is best suitable to individuals, open source software projects, small- to medium-sized companies etc.

Advantages: Being provided as a service, payment options can be flexible (pay-per-use etc.). It is also maintenance free from user's stand point. They generally provide web browser based UI which is easier to use.

Disadvantages: They cater to private repositories by charging extra. They offer limited control over configuration. Being hosted on cloud, they are prone to security concerns.

Hybrid CI Engines

A third option - hybrid approach - is also available. In this approach, typically some agents are deployed on on-premise machines. These agents co-ordinate with cloud servers for building/testing the code. Some of these steps can also be performed on on-premise servers. The artifacts, logs then
can be transferred to the on-premise servers.

Main advantage of using hybrid option is to have more control over resource utilization, configurability and security.

Available Options


Before concluding this series, as requested by the readers, I am presenting a compilation of CI Engines available as of today. Earlier I thought of presenting a comparison, but the comparison table is so huge, I couldn't get it to fit here in a presentable way. Following is a list of CI engines in alphabetical order.


Engine Name
URL
Apache Bigtop
http://bigtop.apache.org/
Apache continuum
http://continuum.apache.org/
Apache gump
http://gump.apache.org/
Bamboo
https://www.atlassian.com/software/bamboo/
BuildBot
http://buildbot.net/
CABIE
http://cabie.tigris.org/
circleci
https://circleci.com/
cisimple/ship.io
https://ship.io/
CloudBees
https://www.cloudbees.com/
codeship.io
https://codeship.com/
CruiseControl
http://cruisecontrol.sourceforge.net/
Drone.io
https://drone.io/
Evergreen CI
https://github.com/evergreen-ci/
Go
http://www.go.cd/
hosted-ci
https://hosted-ci.com/
hudson
http://hudson-ci.org/
Jenkins
http://jenkins-ci.org/
LuntBuild
http://luntbuild.javaforge.com/
magnum-ci
https://magnum-ci.com/
OpenSUSE Build System
http://openbuildservice.org/
pyCI
http://tbraun89.github.io/pyCI/
semaphoreapp
https://semaphoreci.com/
shippable
https://app.shippable.com/
snap-ci
https://snap-ci.com/
strider
https://github.com/Strider-CD/strider/
tddium/SolanoLabs
https://www.solanolabs.com/
TinderBox
https://developer.mozilla.org/en-US/docs/Tinderbox/
travis
https://travis-ci.org/
vexor.io
https://vexor.io/
wercker
http://wercker.com/

So this concludes this series on CI/CD. This series focused on understanding what CI and CD is, its evolution and benefits these technologies offer. It also covered types of CI engines available today, what value add they bring and what could be the points to consider while selecting a CI/CD engine.

I would like to hear your comments and feedback. Also I can discuss and share results of my study with interested individuals.

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

Security in Linux Kernel - Part 3

Image
  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has ...
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