CI Engines



We covered Continuous Distribution in the second part of this series. In this part, let's have a look at what CI engines typically offer.

Typical features of CI engines
  • Access to popular online code repositories
    Most of the engines support online code repositories like GitHub, BitBucket etc. along with traditional repositories based on CVS, SVN and mercurial.
  • XML based build/distribution/deployment pipeline description
    They provide an easy mechanism to specify build specifics, generally in XML format.
  • Build triggers, schedulers
    Build triggers and other notifications are generally provided using web-hooks so that when fresh code is checked in, a build is automatically triggered. More traditional build scheduling is also supported by most of the engines.
  • Automated build and testing
    Build is started automatically once a code check-in is detected. Post a successful build, automated tests are started. Many engines also offer headless browser testing for the project which offer web browser based UI.
  • Clean build/test environment using VM
    Almost all CI engines provide support for VM based or Docker container based builds and post-build testing. Some CI engines can utilize ready-to-use containers available at container repositories such as DockerHub. This reduces repetitive and unnecessary builds of dependencies thereby reducing net build and test time.
  • Wide choice of database engines
    Many CI engines offer choice of current database engines which might be required for post-build testing. Upon request by the developer (through configuration XML file), a vanilla database instance is offered which can then be tailored as per needs by the developer.
  • Multiple mechanisms for status notifications
    Results of every stage of build process and testing can be communicated with concerned parties using different notification mechanisms such as email, twitter, SMS etc.
  • Report generation, publication and archival
    Build and test logs, statistics about time requirements, resource utilization etc. is generated by many CI engines. These results can be published and archived for future reference.
  • Multiple options for delivery/distribution/deployment
    Depending on requirement, the CI engines offer a wide choice of deployment options. The build artifacts can be uploaded to repositories (such as RPMs, Debian packages etc.) or where applicable can be deployed as service at portals like Heroku.
  • Dashboards
    For easy monitoring and control, almost all CI engines offer a dashboard where all the past and present activities can be seen along with their status and artifacts.

Virtualization support


 As more and more developers are moving to virtual computing environments, CI engines are also supporting prominent technologies such as Virtual Machines and Docker containers.

Virtualization ensures that application gets uncontaminated, clean environment for building and testing. Every build and run-time dependency is satisfied by installing it every time a build is started. This ensures that only required and right dependencies are installed (which makes sure builds are self-contained). This happens each time, every time a build is initiated.

All leading CI engines offer virtualization support in some form such as VMs or docker containers. Containers can be pulled and pushed from DockerHub, containers can be chained together to provide required functionality etc.

In the next part, we will have a look at different types of CI engines.

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