GitLab CI is a part of GitLab, a web application with an API that stores its state in a database. It manages projects/builds and provides a nice user interface, besides all the features of GitLab. GitLab Runner is an application which processes builds.

1. CREATE, COLLABORATE AND DEPLOY

2. What is Continuous
Integration/Delivery
(CI/CD)?
Continuous Integration is the practice of integrating
code into a shared repository and building/testing each
change automatically, as early as possible - usually
several times a day.
Continuous Delivery adds that the software can be
released to production at any time, often by
automatically pushing changes to a staging system.
Continuous Deployment goes further and pushes
changes to production automatically.

3. Continuous Integration
• Detects errors as quickly as possible
• Fix while fresh in your mind
• Reduces integration problems
• Smaller problems are easier to digest
• Don’t compound problems
• Allows teams to develop faster, with more confidence
Continuous Delivery
• Ensures that every change to the system is releasable
• Lowers risk of each release - makes releases “boring”
• Delivers value more frequently
• Get fast feedback on what users care about
Why Continuous
Integration/Delivery
(CI/CD)?

4. Registering a
Runner
• First of alI install a Runner compatible with
GitLab CI.
• Install docker if you need to run your builds on
docker containers.
• Go into runner section of your repo and enable a
runner.
• Mention tags carefully as gitlab ci will pick up jobs
according to tags.

5. Add triggers
and
Variables on
Gitlab UI
• First of alI install a Runner compatible with
GitLab CI.
• Install docker if you need to run your builds on
docker containers.
• Go into runner section of your repo and enable a
runner.
• Mention tags carefully as gitlab ci will pick up jobs
according to tags.

6. .gitlab-ci.yml
File
To Enable CI in your repo add
.gitlab-ci.yml file in your repo
at
root level.

7. image: node:4.3.3
services:
- postgres
before_script:
- echo ”It’ll run before every job and stages”
after_script:
- echo ”It’ll run after every job and stages”
stages:
- build
- test
- deploy
job1:
stage: build
script:
- execute-script-for-job1
only:
- master
tags:
- docker
A sample
CI File
It will pull specific
Docker image.
You can find more
images on docker
hub.

8. cache:
untracked: true
key: "$CI_BUILD_REF_NAME"
paths:
- node_modules/
- bower_components/
Cache
Cache all your
dependencies and
library.

9. image: node:4.4.3
before_script:
- 'which ssh-agent || ( apt-get update -
y && apt-get install openssh-client -y )'
- eval $(ssh-agent -s)
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host
*ntStrictHostKeyChecking nonn" >
~/.ssh/config'
- ssh-add <(echo "$GITLAB_KEY")
Note: Do not use this with shell executor.
SSH to your
Docker Instance

10. It will help you to define conditions.
For ex.
build:
stage: build
variables:
GIT_STRATEGY: clone #fetch #none
script:
- echo “build process”
only:
- master@Datashop-Frontend/datashop-frontend
- develop@Datashop-Frontend/datashop-frontend
tags:
- docker
# fetch reuses project workspace
# none reuses project workspace but skip all git
commands.
Variables:
Only
&
Expect

11. It will help you to define conditions.
For ex.
job:
# use regexp
only:
- /^issue-.*$/
# use special keyword
except:
- branches
Variables:
Only
&
Expect

12. It will help you to define conditions.
For ex.
job:
# use special keywords
only:
- tags
- triggers
Variables:
Only
&
Expect

13. It will help you to define conditions.
For ex.
artifacts:
expire_in: 1 week
paths:
- binaries/
- .config
Variables:
artifacts

14. It will help you to define conditions.
For ex.
release-job:
script:
- make zip
artifacts:
paths:
- datashop-
”${CI_BUILD_REF}” only:
- tags
Variables:
artifacts
on
tags

15. For ex.
deploy to production:
stage: deploy
script: git push production
HEAD:master
environment:
name: production
Url:
http://staging.innovaccer.com
Variables:
environment

16. For ex.
Job1:
stage: test
script:
- execute_script_that_will_fail
allow_failure: true
job2:
stage: test
script:
- execute_script_that_will_succeed
Variables:
allow_failure

17. For ex.
build_job:
stage: build
script:
- make build
cleanup_build_job:
stage: cleanup_build
script:
- cleanup build when failed
when: on_failure
deploy_job:
stage: deploy
script:
- make deploy
when: manual
cleanup_job:
stage: cleanup
script:
- cleanup after jobs
when: always
Variables:
when

18. For ex.
build:osx:
stage: build
script: make build:osx
artifacts:
paths:
- binaries/
test:osx:
stage: test
script: make test:osx
dependencies:
- build:osx
Variables:
dependencies

19. For ex.
If your commit message contains [ci skip] or
[skip ci], using any capitalization, the commit
will be created but the jobs will be skipped.
After all, you can not automate all things.
Skip CI

20. http://git.innovaccer.com/Datashop-
Frontend/datashop-frontend-
showcase/blob/master/.gitlab-ci.yml
Example CI file

21. Thank you.
The End