Atul's blogs

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 readil

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 of

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 d

This is a series of articles planned to explain what is Continuous Integration and Continuous Distribution. It also discusses CI best practices, features and types. Further it tries to find out what is the value-add CI/CD brings to the software development, and what points should be consider while deciding upon a CI/CD engine. So, without further delay let's start with the CI first. Disclaimer : The diagrams/images used in my articles are "inherited" from the Internet. I am willing to give proper credit to the author if he/she contacts me. Also, if anybody has any objections about me using these diagrams/images, please let me know and I will remove them from my articles. Continuous integration As more and more projects are embracing Agile development methodology, CI is becoming an integral part of development process. CI is always there in one form or other, right from the beginning days of software development. In the initial days, having a build script and a

Ever since the computer became a personal computer and came within easy reach of masses, writing and sharing software has been an essential feature eventually leading to the Free Software movement. In old days, software was being share by means of paper media, magnetic media etc. In the nascent days of computer networks, the software sharing came in the form of the bulletin boards, maturing along with technology to public software repositories generously hosted by big corporations and research institutes. These days we have dedicated software repositories such as GitHub, Sourceforge etc. teaming with hundreds of thousands of developers and teams. Ever since the first software source code was distributed, there has been a need to provide easy compilation mechanism. Sometimes this came as instruction set in a README file, INSTALL file etc. It was sufficient at the time, as the platforms hosting this software were limited to a very few Operating Systems. With the advent of e

Internet of Things Entire Internet of Things (IoT) can be represented in 3 tiers as shown in following figure. Things comprise of a large number of intelligent sensors or devices deployed in field, which gather information about certain aspect of their environment. These devices interact with the “Infrastructure”. The communication media, Internet and server farm or Cloud, are part of the “Infrastructure”. The third part is the “Applications” which run on a wide range of devices are used by the end-user. The applications consume data produced by the “Infrastructure”. An ideal IoT platform is expected to cover the middle tier (the “Infrastructure”), including the interfaces on both sides. Ideal IoT Platform An ideal IoT platform should be reliable and secure . It should be scalable in terms of number of devices connected simultaneously, capability to handle concurrent communication channels etc. It should provide high availability , ease of integration and should be