CI environment - to pay or not to pay?
Online tests for developers
From a long time every user moves everything to the network: mails, music, photos etc. It was a matter of time when developers would like to move code and tests to the network too. The reason is simple! All developers from the big corporation can make changes and other employees can work with the new code immediately. Responsible for this are code repositories e.g. SVN, Git and CVS. Online tests are equally interesting solution. Developers can see all errors and correct them. It does not need to send the code to others, everyone can perform tests and has access to results. It is very comfortable solution and greatly speeds up the work. However, one fundamental question remains: which platform is the best?
I do not want to pay - Gitlab-CI
The first thought always is an open source solution. We can use standard Continuous Integration system from Gitlab. The newest version this solution was divided into two applications: Gitlab-CI and Gitlab-CI-Runners. Gitlab CI is ran without Gitlab. It is a hook sensitive to push a commit. However, the integration of CI and Runners may be problematic because it requires SSH keys and runner token IDs. GitLab CI is an application which works via web. It uses a databases for operation i.e. creates a project, makes a test, saves a bugs. Every projects are build from web design but user has to have administration role. If Gitlab-CI works with Gitlab, then user must be a member of project/repository on GItlab. CI uses Ruby too and the most problematic is that Ruby is more sesitive for changes. On my server was a situation when second administrator upgrades a PHP version and (accidentally, from the relation) upgrades Ruby from 1.8 to 2.0 version. It has implemented a problem with Runner. It has not run! The second problem may occur when more than one build of this same project is running at the same time. You need to remember that builds which are run at the same moment are cloning and testing on the same directory overwriting each other. The problem can be resolved by Sidekiq configuration or Sidekiq_fetch_limit gem installation. It is also important that the CI host has to be exactly the same as the production machine: the same DB server, libraries etc. For example, in case of Symfony applications tests you have to install (inter alia) npm, nodejs, grunt etc.
The solution for the bourgeoisie - Travis-CI
Travis CI is a hosted continuous integration service. It is integrated with GitHub and offers first class support for: C++, Java, PHP, Python, Ruby etc. User can take advantage of two roads: free or commercial - the software is also available as an open source project available on GitHub website. Although its developers currently do not recommend it for on-premise use for closed projects. In order to build your project for Travis CI, you have to tell the system a little bit about it. You will need to add a file named .travis.yml which is a YAML format text file, to the root of your repository. Great idea! It can change language, compiler and necessary libraries by the one file! After it, system creates separate machines for every projects. It is comfortable when developers have diverse projects - eliminated the problem with configuration of the machine. So, where is the problem? If you do not know what it is, it is about the money! At first, migration for output repository is not safe, spatially when it has private repositories (e.g. bank applications). In this case you have to buy commerce licence. However, it often happens that developers afraid to put the code on the external repositories. Company repositories are usually kept on the local network hosts without an access to the world because of the security policy. However it is not able to deny superiority of Travis over CI and mainly due to the ease of configuration is worth a trying.