Over the past couple of months, 100 projects have joined Vexor. Very different projects with unique settings. During this time, team learned a lot about creating of configuration files. In the process, developers revised their original approach and want to share innovations with you.
Cloud Continuous Integration service. Unlimited parallelism
Practice of merging all developer working copies to a shared mainline several times a day
Remake of launch scripts generation
The configuration file vexor.yml is used in order to understand what tasks need to be done to prepare the environment and run tests in VexorCI. This file is located in the root directory or generated automatically. It specifies the commands that will be executed to prepare the test environment and run the tests.
In the past, in order to convert vexor.yml directly into the commands that the worker performs when running the tests, we:
- The configuration file of built was obtained;
- Sort it out;
- Generated a large bash script;
- Sent the script to the worker.
There were a lot of problems with this scheme:
- It was very difficult to do non-trivial tasks, for example, patching config / secrets.yml in a Rails application.
- Bash is not the most successful language for writing large amount of code, there was a lot of tricky bugs.
- Unclear error messages for the user.
Team decided to change it. Now we:
- Get the configuration of the build in yaml format;
- Convert the intermediate representation to a file, also in yaml format. The very structure of the file is made by analogy with ansible.
- This file is sent to the worker for execution.
Renouncement to generate a giant shell script allowed to manage the deployment environment more flexible, show users understandable error messages and forget about hard-to-solve bugs in the shell.
Change of keys assignment in the configuration file
To start using VexorCI, writing a configuration file is completely optional. Unfortunately, in the old version there were situations when the tasks generated by default collided with tasks specified by the user in the configuration file.
In order to avoid such conflicts in the future, all the settings related to the databases that used to be in the 'before_script' key should now be in a separate key - 'database'.
# was before_script: - rake db:create - rake db:migrate # now database: - rake db:create - rake db:migrate
Using a separate key for databases makes the configuration easier and more understandable.
CCMenu is supported
CCMenu is a popular application that displays build statuses in the toolbar and allows you to always be aware of what is happening on the CI server. Now projects from VexorCI can easily be added to the CCMenu.
CCMenu URL at Vexor "Settings
Go to "Settings" of your project and copy "CCMenu URL"
Feed URL tab in CCMenu
Paste this URL to a "Feed URL" field.
Now it's much easier to monitor the build status.
Use Vexor and get rid of any restrictions and unfair price. Connect and receive $ 5 on your account to check out Vexor.
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?