Most recently, guitarlah heroically rolled out version 8.0 of its rival githabu. From the interesting - the continuous integration engine is now built into the platform, which means it is available as a free service for everyone on gitlab.com . Together with free private repositories, this makes the gitlab cloud service not only a convenient place to store code, but also testing and deployment. I also will tell about the last under a cat.


Continuous integration is not only the launch of unit tests when pushing new code to the repository. It is also an opportunity to build products, publish them to stores, websites and other distribution channels. Voximplant cloud telephony uses javascript scripts that are hosted in our cloud and executed by the command “outside” or when an incoming call arrives. Many scripting clients use a text editor built into the admin panel, which is quite suitable for simple cases. But when developing and supporting complex cloud systems, for example Bitrix24 telephony, something more serious is needed.


Creating voximplant we decided not to push-to-deploy like with heroku. For many of our clients, the main business is not connected with the development of software, and leaving them alone with git is not very good. On the other hand, there is an HTTP API with a “zadlopleit script” function, which hints to understanding people that scripts can be stored on gitlab and deployed using a shell script and curl. Most clients do just that, but the approach has a serious drawback: you need to remember to call the script. Moreover, it is necessary to call it only if the code was launched in the production branch. And only after passing the tests. There are many ways to make mistakes.

Setting up continuous integration in gitlab

')
By default, continuous integration in the gatelab is disabled and you need to enable it in the settings:



After turning on the project’s left menu, several new items appear, the most interesting for us is “runners”. Continuous integration in the gitlab works as follows:

1. You push to repository
2. If there is a .gitlab-ci.yml file in the project root, then gitlab understands that continuous integration will be used for this project.
3. Hitlab is looking for a running runner connected for this or for any project. Runner is an application that is usually run on a separate computer and which will actually perform continuous integration: run tests, build executable files, implement warmth. You can run your runner, for example on a poppy to build an application for iOS. You can use the “gitlab public runner”, but they are not that very safe and the incoming task queues are usually many hours long.
4. Gitlab transfers the yaml runner file, which updates the sources in its repository and executes the commands described in this file. Commands can be as simple as, for example, deploying a script into a voximplant cloud. So it’s complicated: launching a docker container, building a project in it, running tests, and so on.
5. After running the scripts, the runner reports back to the gitlab the results that can be viewed next to the corresponding commit.

Install gitlab ci runner

For our example, we run the runner on the developer’s machine. Installation instructions for windows / linux / osx are available on the official website , after installation we get the command line utility gitlab-ci-multi-runner . Running runner connects to gitlabu and waits for build tasks. But how will the guitar team know what tasks to which runner to give? To bind the runner to your account and project (or several projects), you need to call gitlab-ci-multi-runner with the register key and enter the connection parameters: url gitlab (since the glab may be deployed locally in your network) and the registration token, which, in fact, determines the account / projects:



The registered runner is started by the gitlab-ci-multi-runner run command and is waiting for a task from gitlab. Using the command line keys, install and start runner can be registered in the system as a service so that it automatically starts after the operating system is rebooted.

Configuration of continuous integration for deployment

As I already wrote, the tasks of continuous integration are described in the .gitlab-ci.yml file which must be placed in the project root. The rare-earth syntax YAML is a human-readable alternative to JSON, the documentation is available on the official website . The configuration file for project deployment to voximplant will be as simple as possible; all we need is to make one HTTP API call as described in our documentation . Assuming that the runner is executed on the computer where curl is installed, and the scenario code is in the scenario.js file, the configuration file for the deployment will look like this (A simplified example. This one will, for example, api_key make sense in the environment variable , see the nmike comment):

before_script: - npm install stages: - deploy deploy: script: - curl -X POST "https://api.voximplant.com/platform_api/SetScenarioInfo/?account_id=1&api_key=2&required_scenario_name=foo" --data-urlencode scenario_script@scenario.js 

In curl, we use the syntactic sugar of our API, which can take arguments in both the query component of the url and the body http of the request.

For continuous integration to work, it’s enough to push to the repository: gitlab will find the .gitlab-ci.yml file , find the connected runner, give it the contents of this file, runner will update its copy of the repository and run the deployment script that will ship the source code to our cloud.

Questions, clarifications, comments? Gitlab vs Jenkins vs Bamboo vs Teamcity?