Automatic code check using Vexor.io

19 May   1130

RuboCop

A Ruby static code analyzer, based on the community Ruby style guide.

I think, many are familiar with the Hound service for automatic code check. When you create a new Pull Request on GitHub, Hound launches a checkup of your code based on such solutions as rubocop, haml-lint or scss-lint. If any problems pop up during the checkup process, Hound will report on it by adding the corresponding commentary to your Pull Request. It is a great work tool, but you know what they say – all good things come with a price.

Hound landing pageHound landing page

 

Vexor

Cloud Continuous Integration service. Unlimited parallelism.

Not every company is ready to pay this much money, so I decided to take a different approach. I used the pronto library as the basis since its out-of-box version does everything Hound can. The only thing left is integrating pronto with Vexor. The following is a step-by-step manual for what has to be done.

First you go to GitHub and generate a personal token.

Creating personal token at GitHub
Creating personal token at GitHub

Then you add two environment variables in the properties of your Vexor project.

Adding environment variables in Vexor project
Adding environment variables in Vexor project

Then you add pronto and several of its plug-ins to you project’s Gemfile. To view the list of available plug-ins, click here.

group :test do
  gem 'pronto'
  gem 'pronto-brakeman', require: false
  gem 'pronto-coffeelint', require: false
  gem 'pronto-fasterer', require: false
  gem 'pronto-flay', require: false
  gem 'pronto-haml', require: false
  gem 'pronto-jshint', require: false
  gem 'pronto-rails_best_practices', require: false
  gem 'pronto-reek', require: false
  gem 'pronto-rubocop', require: false
  gem 'pronto-scss', require: false
end

Launching pronto requires creating a bin/pronto file:

#!/usr/bin/env ruby

require 'bundler/setup'
require 'pronto'
require 'pronto/cli'

begin
  Pronto::CLI.start
rescue Octokit::NotFound
  puts 'Pull Request Not Found'
end

And giving it chmod access:

$ chmod +x bin/pronto

Now all you need is to add several instructions to .vexor.yml:

language: ruby

script:
  - git remote set-branches origin '*'
  - git fetch
  - git checkout $CI_BRANCH
  - bin/pronto run -f github_pr -c $DEFAULT_BRANCH
  - bundle exec rake

And that’s it, it is now ready for checkups.

Final resultFinal result

Some would object: why would you need all this when you have overcommit? New project developers often forget to tune overcommit, and this is only found out several days later when another developer isn’t able to send the changes he made to the server. To exclude situations like that, I recommend using these tools together.

P.S. I’d like to thank Sasha Kirillov for his help in integrating pronto with Vexor.

Which CI do you use?

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. There are a lot of different continious integration solutions with strong and weak sides.
Take part in the survey of our portal. Which Continuous integration system do you use?

Vexor at HighLoad++ 2017

Alexandr Kirillov reported about how to build a cluster to calculate thousands of high-CPU / high-MEM tasks at one of the biggest Russian IT conferences
12 December   3520

The HighLoad++ is professional conference for developers of high-load systems is the key professional event for everyone involved in the creation of large, heavily-frequented, and complex projects.

Main purpose of the event is to exchange knowledge and experience among leading developers of high-performance systems, which support millions of users simultaneously.

Agenda consists of all crucial web development aspects, such as:

  • Large scale architectures,
  • databases and storage systems,
  • system administration,
  • load testing,
  • project maintenance, etc.

This year the conference program will be dazzled with current trends: IoTBlockchainNeural networksArtificial Intelligence, as well as Architecture & Front-end performance.

The 11th HighLoad++ conference took place on the 7th and 8th of November 2017. 

  • 66% of participants work in large companies (of 30+ employees), 
  • 60% earn above the market, 
  • 55% hold leadership positions and have subordinates. 
  • 9% of conference visitors work as technical directors,
  • 12% work as heads of technical departments, and 29% work as lead developers and team leads.

Alexandr Kirillov, CTO at Evrone, had a speech at HighLoad++ 2017 "How to build a cluster to calculate thousands of high-CPU / high-MEM tasks and not go broke"

Alexandr Kirillov at HighLoad++ 2017
Alexandr Kirillov at HighLoad++ 2017
Alexandr Kirillov at HighLoad++ 2017
Alexandr Kirillov at HighLoad++ 2017
Alexandr Kirillov at HighLoad++ 2017
Alexandr Kirillov at HighLoad++ 2017
 

Our project is a cloud-based CI-service, where users run tests of developed projects.
This year the system of auto purchase of our project purchased 37218 machines (Amazon Instances). This allowed us to process 189,488 "tasks" (test runs) of our customers.
 

Tests are always resource-intensive tasks with the maximum consumption of processor capacities and memory. We can not predict how many parallel computations and at what point in time it will be. Before us was the task of building the architecture of the system, which can very quickly increase, as well as rapidly reduce the power of the cluster.
 

All this was complicated by the fact that the resource-intensive calculations did not allow us to use the classic tools AWS or GoogleComputeEngine. We decided to write our own system of automatic scaling, taking into account the requirements of our subject area.
 

Alexandr Kirillov
CTO, Evrone

At his report, Alexandr told about how they designed and built the architecture of the service, which is the system of automatic procurement of machines.

Additionally, he told more about the main architectural blocks of projects that solve similar problems.