Using gitlab continuous integration for deployment

    More recently, a gitlab heroically rolled out version 8.0 of its rival github. Of interesting things, 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 test and deploy. I’ll tell you about the latter under the cut.


    Continuous integration is not only about launching 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. Cloud telephony voximplant uses javascript scripts that are placed in our cloud and are executed by a command “outside” or when an incoming call arrives. Many script 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, such as Bitrix24 telephony, you need something more serious.


    When creating voximplant, we decided not to push-to-deploy like heroku. For many of our clients, the main business is not related to software development, and leaving them face to face with git is not very good. But there is an HTTP API with the function “deploy the script”, which hints to understanding people that the scripts can be stored on gitlab and deployed using the shell script and curl. Most clients do this, but the approach has a serious drawback: you must remember to call the script. Moreover, it must be called only if the code has been launched into the production branch. And only after the tests passed. In general, there are many ways to make mistakes.


    Setting up continuous integration in gitlab



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



    After switching on the project settings in the left menu, several new items appear, the most interesting for us is “runners”. Continuous integration in hitlab works as follows:

    1. You do push to repository
    2. If there is a .gitlab-ci.yml file in the root of the project , then gitlab understands that continuous integration will be used for this project.
    3. Gitlab 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 carry out continuous integration: run tests, collect executable files, and deploy. 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 very secure, and the incoming task queues usually have many hours.
    4. Gitlab passes the yaml file to the runner, who updates the sources in his repository and executes the commands described in this file. Commands can be as simple as, for example, deploying a script to the voximplant cloud. So complex: launching a docker container, building a project in it, running tests, and so on.
    5. After running the scripts, runner reports back to the hitlab the results that can be viewed next to the corresponding commit.


    Install gitlab ci runner


    For our example, we will run 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 at our disposal . The running runner connects to the hitlab and waits for the build task. But how does the gitlab find out 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 gitlab can be deployed locally on your network) and the registration token, which, in fact, defines the account / projects:



    The registered runner is started by the gitlab-ci-multi-runner run command and waits for a task from the gitlab. Using the command line switches install and start runner, you can register as a service on the system so that it automatically starts after the operating system reboots.

    Continuous integration configuration for deployment


    As I already wrote, continuous integration tasks are described in the .gitlab-ci.yml file, which must be placed in the root of the project. The rare-earth YAML syntax is a sort of human-readable alternative to JSON; the documentation is available on the official website . The configuration file for deploying the project in voximplant will be as simple as possible, all we need to do is make one HTTP API call as described in our documentation . Based on the assumption that runner is executed on the computer where curl is installed, and the script code is in the scenario.js file, then the configuration file for the deployment will look as follows (A simplified example. There will be a bigger one, for example, it makes sense to put api_key into an environment variable, see 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


    Curl uses the syntactic sugar of our API, which can take arguments both in the query component of the passed url and in the body of the http request.

    For continuous integration to work, it is enough to push into the repository: gitlab will detect the .gitlab-ci.yml file , find the connected runner, transfer the contents of this file to it, runner will update its copy of the repository and run the deployment script, which will upload the source code to our cloud.

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

    Also popular now: