Full video and summary are here: https://www.almtoolbox.com/blog_he/gitlab-ci-cd-webinar/

00:06 
Hello everyone and thank you for joining us
00:09
I'm Tamir Gefen and I'm the CEO of ALM-Toolbox
00:12
We're a Premier partner of GitLab company
00:15
and we provide professional services of GitLab
00:18
training, private hosting and selling of licenses
00:20
to customers from whole over the world
00:23
Today I'm hosting Xiaogang Wen, Solution Architect at
00:26
GitLab company
00:28
Xiaogang is joining us from Beijing China
00:31
Can you hear me? How are you?
00:34
Good morning everyone
00:37
OK great. Thank you for joining us
00:39
So today we are going to cover the following
00:44
First we will see an overview of CI/CD included in GitLab
00:48
then we will see a demonstration of how GitLab CI/CD is integrated with software
00:53
development lifecycle and then it's time for questions and answers and if you want
00:58
to ask some questions in real time you can use the chatter below and finally
01:02
we will have time to learn how to get started with GitLab CI
01:08
Let's get started are you ready? yep okay great good luck
01:13
so I'm sharing, you can take access to share your screen ok?
01:20
so the first slide of GitLab. Everyone can contribute
01:25
This is one of the key culture of the company
01:30
okay, so CI/CD overview just talk about current state of DevOps, so here
01:40
in DevOps, a common DevOps process, this is not by GitLab but by everyone,
01:47
so you have a few stages like idea like issue planning, coding, commit, test, review
01:53
staging, production and feedback. so in all these stages we probably usually group
02:01
them into a few ones like below so you have plan, code you have test, you
02:08
have deploy and finally once everything is done you do, you run
02:14
analysis so in this comment there are features required like below
02:22
so in plan stage you all in need all these then when you do coding you need
02:28
like coding management like merge request so in the past you need what
02:36
happened, so you need CI then deployment that's CD or automatic or
02:44
manual deployment therefore analogous you need to do promise monitoring you need
02:50
to do analytics over your whole life cycle so next thing, so nowadays GitLab
03:01
can do everything so we notice here I replace the CI with GitLab yet
03:06
because in this session will focus more on GitLab CI/CD, so this is our
03:14
focus this is about CI and CD regarding GitLab CI itself it's now in a good
03:25
position in the industry so this report by Forrester was published on I think
03:34
September of 2017 so you can see here we are we're on the red top means we have
03:42
the highest score for the current offerings or current existing
03:47
capabilities and we also had a position of highest possible means we are we
03:55
have the rest strategy for the feature
04:04
then a lot of people ask
04:08
I'm using Gitlab for republic hosting for product planning why should I
04:17
consider GitLab CI/CD? so we have a few reasons I talked about all these reasons
04:24
first, then I will go to the features of GitLab CI/CD so first of all its
04:31
integrated, it's part of GitLab, so with GitLab CI you know you don't need to
04:37
configure the repository. you don't need to configure the repository means you don't
04:42
need to provide the URL provided credentials or whatever, so it's easy to
04:48
learn or easy to start I'll talk about that through the demo how you can
04:53
configure how you can start to use GitLab CI although the demo itself may
04:58
not be, it may not be that easy but I'll walk you through so beautiful
05:05
means same experience with GitLab we use GitLab for other purpose like a code
05:11
management like product management
05:14
so it's let's say it's the same experiments so people do now need to
05:19
learn all different languages language means that two languages not C or C++ or
05:25
Java, scalability this interesting topic I will talk about this
05:31
later it means you can run multiple are
05:36
runners it means you can have runner as Auto scale so faster results means you
05:44
can do parallel jobs in a very easily which I'll cover later so the continuous
05:53
delivery also also included means so we have the deployment concept we have the
06:00
we have the environment concept and verbal support so we do have a very kind
06:07
of a very complete various spot which I will explain later
06:12
so lastly GitLab CI/CD is open source all mostly open source I think good percentage
06:22
of the CI/CD features are open source so means you can find the code fronted
06:29
everywhere so you can share the experience with others about given
06:34
CI/CD you see you can view the source code you can even add teachers by yourself
06:39
take these other reasons that why you need to consider GitLab CI/CD
06:46
it's not perfect but it's very good
06:49
ok now let's talk about GitLab CI/CD features so number one it's about the
06:56
architecture benefits means the benefits from the architecture of the GitLab CI/CD itself
07:03
first one is CI definition it's using Yaml file by default is
07:19
.gitlab-ci.yml but this one it's configurable you can use a
07:27
customized path for that I skew like so
07:40
when you use these and note
07:45
a little bit difficult because you need
07:50
to write down something I know some people prefer use kind of
07:55
wizard or UI but when you use these kind of Yaml file you can version control over everything
08:00
it's about your CI process it's about
08:04
your environment definition if you use a Docker as your runner environment
08:10
you can also can version control the CI environment itself like in which version
08:18
of image like Ruby like in previous release on this branch you are using
08:26
Ruby like to the file and the other ones to the sakes this gives you to version
08:33
control over everything is one of the key elements for Auto DevOps so the next
08:41
thing is about parallelization so to achieve parallelization in GitLab CI
08:45
it's pretty straightforward you just need to define
08:50
multiple jobs in one stage they will run in in parallel
08:56
The next thing it's about aboot in it's about built-in CI/CD
09:04
as I mentioned earlier you don't need to configure all those stuff
09:09
and we also have built-in container registry so with this view in container
09:15
registry it's easier it's faster for you to retrieve to publish your your container image
09:22
and also there's another benefit of using built-in container registry
09:28
is access control it's the same as your product so you don't need to
09:35
define another reason to control access lastly here is about GitLab CI/CD horizontal
09:42
auto scaling so I have details on my separate slides on these
09:49
so lastly only slides it's about GitLab runner
09:53
A Runner is kind of agent there were runners the place that
09:59
you run your actual task of your CI/CD so for GitLab runner
10:06
you can have shared runner which will be available across the whole
10:11
instance all the defined group share runner or products basically runner so
10:17
at different levels so I didn't add here but we do support
10:23
tag of runners so we do spot tag of runners so you can you can tap your
10:28
runner for different configuration of what different purposes
10:33
Next slide is about OS architecture support
10:42
so here the most common wise like Linux like Windows like Mac OS we we all support them
10:49
but for FreeBSD not out of the CI tools support and furthermore we support
10:57
Linux ARM and that basically things the runner program application
11:03
is written in Go language so as long as your operating
11:10
system or all your architecture is supported on that is supporting Go language
11:18
GitLab runners should be able to support that or you can distribute GitLab runner
11:25
by yourself for that architecture so further than that we
11:31
also support SSH protocol means as long as you're perfect platforms to pause as
11:40
head as a search okay no as a safety diamond then you can use our assets
11:47
executors to run the CI task remoley so lastly can running GitLab CI from
11:55
docker container from Kubernetes cluster so means a pod in Kubernetes cluster
12:01
okay there are a few ways to run your pipeline so like by default by commit or
12:11
you can run by a click through the UI or you can run by a trigger
12:17
through API or through web hook so this is a way for automation with GitLab CI/CD
12:27
with external systems so for example you have another system at some event 120 00:12:35,800 --> 00:12:41,940 you want to trigger the GitLab CI then it's the way we do traps scatter
12:42
so with NASCAR you can also put variables. I'll talk about variables
12:48
later. schedule UI or schedule API so either way you can use them well most
12:57
part we have a list of variables at different levels, software levels, they are
13:03
spotted in this priority so in short most closer to the runtime
13:13
and gets the highest priority. runtime trigger variables or scheduled
13:20
pipeline variables. Oh actually there's another one I didn't include here it's
13:25
run pipeline UI they take the highest priority. Then next project
13:33
level definition, group level definition, then YAML definition at job
13:40
level, at global level.
14:00
We have predefined variables, which you can actually utilize
14:06
them in your CI for example you want to print out the URL of the label or the
14:11
project ID or whatever if you want to do something or name something based on
14:18
unique values of those variables you can utilize this but they they take the
14:24
lowest priority they take the lowest priority so
14:29
if you have definition on a higher level there will be...
14:38
I wouldn't say they will be overwriting but the result may not be
14:50
something you desired. Auto-scaling so officially we have a docker machine-based
14:58
runner as the auto scale option and at gitlab.com we used docker
15:09
machines to provision gitlab runners - I think for both paying users and the
15:19
free users - in this case previously it was on Digital Ocean and now we are,
15:26
I think we switched to Google cloud so basically as long as docker machine
15:33
supports that cloud then you can use that. So we have customers using docker
15:39
machine-based the auto scale runners on AWS as well, so then
15:47
Kubernetes-based means they use Kubernetes runner so the actual runner will be
15:52
provisioned on demand so as long as your Kubernetes instructions support you
15:58
can do that and also there's a kind of concurrent definition so
16:04
if you could define your concurrency as for example as 8 then
16:11
maximally you can have that. So similarly for docker machine-based solution you
16:18
also have a maximum definition. So lastly docker-based it's similar
16:24
to Kubernetes-based solution it's provision on demand what I put a
16:30
question mark here is you read people do not use it in that way because each
16:37
individual docker may have a limited capacity so you are really limited in
16:44
number like just four or two. These are all our autoscaling options. Next thing
16:54
is very important and very interesting we call these review apps.
17:01
it may be the only one may not but it's one of our unique features. Basically
17:07
it's a dynamic environment for branch either a feature branch or a bug fix
17:14
branch so basically is a dynamic environment
17:17
it's provisioned and it's automatically available when you deploy your staff
17:25
your feature branch staff to a dynamic environment through a review app
17:32
environment so it will show up as a link here as a link here in your merge request 163 00:17:39,000 --> 00:17:43,800 widget you can also find it in your environment tab but the people you
17:43
really just pick it up here most useful for web applications so review
17:51
apps you can use a review apps for other application but it's not that helpful if
17:56
you noticed if you have tried it - to contribute a merge request to gitlab.com I
18:05
mean our website about popular you probably have seen a lot of these so
18:11
because gitlab.com it's kind of a static website but the content itself
18:21
it's generated by the website generator so it's kind of complicated
18:28
it consists of a lot of a data files multimedia files so when you make simple
18:35
change to add data file like a
18:41
feature definition file then you may not know the exact results then this the way
18:48
how you can preview that on your branch before you have it merged. This is the review
18:55
apps so if you do a web site deployment I strongly stress you to try
19:03
this out ok we do have another few a good list of
19:09
enterprise features for GitLab CI/CD so for example for external repo support
19:15
you can connect GitLab CI/CD with external repo then GitLab
19:21
can pull the change and run a CI pipeline for you and also we
19:31
have customer project template so you can create some
19:37
project, I think, ahead of time with a folder
19:41
structure or even with existing files along with the CI definition
19:47
then later if you have a lot of new projects we just
19:55
need the same or similar configuration to create the project from the template
19:59
that will save you a lot of time and also help you with standardization
20:04
So we have a code quality product I think he said a Code Climate based if
20:11
you have these you can run GitLab CI to scan your code then gather a report
20:17
available on merge request as well Next one is also very useful and is
20:25
being asked for by a lot of customers is about inclusion so you can have
20:32
common moduls like common script predefined then you can include them
20:38
into into your CI/CD definition that can help you to save
20:45
time that can help you to do the standardization or even enforce
20:49
some policies Custom file templates - this can be used to
21:00
provide your own template for some CI definition files so it's something you
21:06
can also use later there are a few other deployment-related like the
21:12
Deploy Board like every deployment incremental promise those are all
21:17
supported by the Enterprise Edition Lastly the very latest feature is a
21:25
built-in Maven repository this is a very recent feature for GitLab Premium Edition
21:34
so with this one you can just deploy
21:38
your artifact to the Maven repository then
21:45
it can be consumed by internal or external jobs of pipelines. Those are
21:54
all these and lastly I think this last one: Auto DevOps. A lot of people heard
22:00
about the GitLab Auto DevOps, made them interested in GitLab Auto DevOps .
22:07
Auto DevOps is something it's kind of feature that GitLab CI/CD can
22:13
automatically detect and build and test and monitor your applications so
22:19
you can even start your project without a Docker file then the
22:27
auto build will detect your code framework and build it and pack it into a
22:33
Kubernetes image then run the automatic path based on Heroku buildpack detection
22:41
then open it and run a code quality run study and application security
22:46
testing, dependency scanning, license management. All these and if it's on a
22:54
feature branch it will just spin up a review apps if it is on
23:02
master we will just do staging deploy to staging so once you
23:08
have your stuff deployed it will run the automatic browser performance test
23:15
Plus you can see the results you can monitor the result through our
23:20
Prometheus tool. I know it has taken
23:28
longer than expected but I hope this can be helpful to you
23:33
so it's last one I think we probably can leave the questions to the end of the
23:41
session yes yes okay thank you very much thank
23:48
you very much again in just a second okay
23:53
yeah I have some questions that we we've been asked there in advance and also to
23:58
see another another few questions in real time so just a second I just want
24:04
to make sure we have enough time yeah we probably have enough time for all
24:07
questions hopefully okay so I will ask the questions and then you will
24:13
provide answers okay yeah yeah okay so first question is what
24:20
about integration with Openshift and Kubernetes? So that's a good question so
24:27
it's if you do deployment it will be they will be the
24:34
same integration with OpenShift Kubernetes, they
24:39
will be the same let me show you something here is my screen it's already
24:44
shown being shown let me find any project maybe let me find something here
24:52
it's gitlab.com I just want to show you the
25:00
place to do the integration switch to personal we I have the few I think I
25:08
can show you this one so it's actually here it's a Kubernetes we have a
25:16
specific menu here I'll turn it off I know the problem because let me let me
25:30
do this let me remove the existing one
25:50
because now it's a pivate project maybe let me just turn it to a public project
25:57
so on gitlab.com if you have any public project you will have access to all
26:05
premium or ultimate features so I made it public now that if we take a look at
26:13
Kubernetes we can add a new Kubernetes cluster so in this way you can create a
26:23
new cluster on GKE. This feature is kind of fantastic especially for
26:30
people like myself I'm not that crap for me terrific GKE itself but if I use
26:36
these it is very easy or if we have easy any customers clusters so no matter it's
26:42
Openshift or it's a Google GKE as long as we have the API URL you have
26:49
the CA certificate and it's all good then we can add integration so with the
26:55
integration then you can easily deploy your application to the cluster
27:01
so I don't have one maybe I mean they take time I won't try that if we
27:09
have ten more minutes that's fine that's fine I think it
27:13
answers your it answers a question so now just let me understand, do you
27:18
plan to to show the live demo after the questions, do you have any?
27:25
yes I will but sometimes it takes longer time sometimes
27:30
it's just two minutes okay yes sure okay so I'm moving forward to look to the
27:39
next one yeah so just a second how to get started the general options explains
27:48
so I think we will talk about it later yeah yes even though I can talk
27:56
and have a very brief description so basically for GitLab CI/CD
28:05
you know you have to define where you run you have to provide the place to run
28:11
a task, that's GitLab CI runner so you have to install and address the runner number one
28:18
number two is for your product you need to provide that pipeline definition
28:23
that's the YAML file: .gitlab-ci.yml, that's the YAML file
28:30
or you can define using a custom path so those the
28:39
top two so once you got them you just need to enable it in GitLab settings
28:45
here in GitLab settings > permissions
28:53
As long as you don't turn it off now once you commit your pipeline will be
28:59
started so that's the brief description so it's easy right yes yes okay yeah and
29:09
and I think we can provide the hyperlink afterwards with how to get
29:14
started yes the page yeah okay okay so next question okay just a second next
29:25
question is a can GitLab CI/CD replace Jenkins ah that's a good question but
29:34
answer you know whether I will say yes but I
29:38
I said technical person I wouldn't see a hundred percent so means as long as you
29:47
don't need Jenkins specific reports you know Jenkins has a lot of
29:53
plugins some of the plugins they need to offer you whether a good report or
29:59
dashboard that's something we don't have all we don't have all of them in a
30:03
moment so if you rely on those you probably still can come and kill out
30:11
with Jenkins otherwise it would be very easy for you to switch
30:16
from Jenkins to GitLab because it you know it's very straightforward defining
30:21
your CI definition file then Jenkins lets convert you to GitLab CI runner okay
30:31
yeah and I see there are another two questions related to Jenkins so if
30:35
you want to refer to them another one is about the
30:41
comparison with Jenkins if you can yeah and another and there is a second one
30:46
how to connect GitLab with Jenkins yes let me answer the first
30:53
one yes sure operation yeah if you I wouldn't I do
30:59
that but if you like you can do these you told to you can do a Google "GitLab Jenkins Comparison"
31:04
I hope the first one pop up is our website but
31:19
but no this is the one so there are a few summary
31:32
so to say comparison so basically if you want to know more it is here, but in
31:39
short number one it's about being all-in-one application I wouldn't call
31:45
GitLab solution it's all-in-one application or a CI on me
31:51
so Jenkins even does not do much CD things it does not have environment
31:57
definition, right, if you want to do that it's everything by yourself it's all-in-one
32:03
application or CI only tool. So when you need to
32:09
connect to Jenkins have to provide a few informations like the repository name
32:15
and credentials but with GitLab it's all there you just need
32:20
to run enable CI and run CI on project and the CI process will
32:27
run for you automatically. So number one reason and the number two
32:35
a lot of people appreciate a native support of container environment you know a
32:43
lot of people using GitLab CI/CD run their CI or CD tasks within containers
32:52
this is something we support natively I know Jenkins makes for that but it's
32:59
not as native as GitLab and there are a few other
33:05
differences like I had mentioned for auto-scaling
33:08
that's for GitLab is very easy if you use docker container, use docker machine
33:14
Or another thing is parallelization so like I said for GitLab is just need
33:21
to put your job inside a stage they will just run in parallel
33:27
For Jenkins you probably have to achieve that by your own script
33:32
I know you can do that by your own script but it's again it's not as
33:37
straightforward as GitLab so lastly it's not may not be lastly but
33:47
the important thing is for Jenkins if you want to achieve a specific purpose
33:53
you probably need a plugin meaning one plugin two plugin three plugins then
34:01
you probably may have a hundred plugins it will be very hard for you to maintain
34:06
that. For GitLab we have only one which ensures all the
34:11
integrations included inside GitLab CI, all the integrations for a
34:18
specific release of GitLab we work, everything is done by GitLab,
34:23
it's not done by you, all the integrations including CI integrations. Lastly it's
34:30
about Kubernetes support. If you want Jenkins to do the same as GitLab for
34:37
deployment to Jenkins or to Kubernetes you probably need Jenkins
34:45
adds, which are a hundred percent different things than Jenkins. For GitLab
34:51
it's the same, it's built-in so that's my kind of
34:58
takeaways about the differences between the two.
35:04
yeah thank you very much right yeah you can integrate Jenkins wth GitLab. Yeah how
35:12
do how do you integrate them both? so uh basically it's about the integration can
35:20
only be done in one way: use GitLab for repository and use Jenkins for CI/CD.
35:26
you can't use Jenkins as repository and GitLab for CI/CD so there's only one
35:33
way is pretty straightforward: here there is an integration if you scroll down
35:38
there's Jenkins CI.
35:42
Then you need to provide all these and on Jenkins side you need
35:50
to install these two and to configure. On Jenkins side you need to install Git
35:55
plugin and GitLab plugins so after that you can configure all these
36:02
then once you push your code to GitLab there will be a kind of a webhook
36:11
notification to Jenkins then the Jenkins job (not job, in Jenkins it's build)
36:17
will be triggered, or if you want a merge
36:22
request to do the same you can check these on as well. So basically two things:
36:28
For GitLab side you need to turn the integration on and provide all the
36:34
information and on Jenkins side you need to install and configure these two
36:41
plugins. There are more detailed information here too
36:47
you can take a look here for all these details which include
36:54
the configuration on both sides.
36:58
That's about integration. OK ok ok thank you very much
37:02
so now I see few more questions another question asked what about specific builds
37:09
within a micro-services architecture. In that way,
37:20
it's not as straightforward as for a single product build, in that way we support always
37:27
- just you to turn on these (I hope I could find this out) you can turn on these:
37:39
"Multi-project pipeline graphs". If you are on the price then we think one project
37:46
in one CI definition well you can use like Crow or whatever other way to
37:54
trigger another build, to trigger another pipeline for another component of your
38:01
macro services architecture so we probably will have status code on these but at
38:07
the moment that's the way we stress you turn on these it's not turned on for its
38:12
own. If you are Enterprise be automatic on and you can use curl to call another
38:21
using kind of a webhook over API to trigger the pipeline from another
38:28
component so that's the way we stress you to do now you know inside one
38:35
project inside one stage you can build another two in parallel
38:41
or in another three in parallel if you have to if they don't depend on each
38:45
other but if they do you have to put them into different stages. For example if
38:52
you have like dependency first you need to build dependency early stage then
39:00
you can consume that dependency early in your later stage so that's something can
39:07
only need to also consider hope that can help a little bit yeah
39:13
yeah sure I hope so okay another question are there any Kubernetes
39:19
executors working with GitLab? Yes definitely definitely.
39:25
I have I think in this example we do have the Kubernetes runners here.
39:38
All these shared runners they are Kubernetes runners so there actually a
39:47
few ways to that. Number one if you provision your GitLab environment using
39:54
our latest cloud native Helm Chart then a Kubernetes runner will
40:02
be provisioned as well at the same time, that's one way. Second way is when you,
40:11
like I said, let me use this example, so second way is when you
40:20
provision, when you connect either create a new cluster or add
40:28
an existing cluster will connect your GitLab project to a new Kubernetes
40:35
cluster once everything is done and the connection is established then you have
40:42
a few options maybe... Let me do this I just want to show
40:54
you I think we have a UI screenshot here... I don't like this one but I like
41:09
the documentation I think this is the one... Okay, so once you
41:29
have a connection established after you install GitLab Helm Tiller, after you
41:37
establish connection then you have to install Helm Tiller to your cluster
41:43
so after these you can install GitLab Runner into your Kubernetes cluster by
41:51
one click and once it's installed it will be available as your
41:58
project specific runner. So this is another way. There are even further ways
42:04
like you can deploy a Kubernetes runner to a Helm Chart, so
42:13
there are quite a few ways to do that. Okay, yeah, thank you very much
42:18
so I see we have another we have 15 minutes only so let's take
42:24
the last question please. So it goes like that: say we have another
42:29
Docker registry and also another provider for Git repo would it be
42:34
still efficient to utilize GitLab just for CI/CD? Yes that's something doable.
42:42
Like I said we support you to create, we support you to use GitLab for CI/CD-only
42:53
purpose then when you create a new project
43:05
you have the option to create "CI/CD for external repo" so there are two ways
43:13
generic repo by a URL the other one is GitHub If it's a generic repo by URL
43:20
you just need to provide your URL then once the new project is created on GitLab side
43:26
it will pull the changes from external repo when there's
43:31
any new commit the CI will be run automatically If you have configured CI/CD
43:40
like runner like turn on and as well as running but if you connect if you run
43:49
it for GitHub then it will be even more advanced like nice there's any push to
43:58
your GitHub repository then we have the web hook notification to GitLab side
44:05
GitLab will actually sync with your GitHub repo and run a pipeline
44:15
after the pipeline you will even report abuse data back to GitLab so that's the way
44:20
so in that process you can also talk to external content or registry external
44:26
artifactory so you can find all the examples online
44:34
Thank you very much I think we covered all questions so
44:38
next step is a demo and then we're getting started. I think we'll just do a demo we
44:46
probably don't have time to talk too much on getting started well we have
44:54
13 minutes so if you can do a quick demo and then just took a few more minutes
44:58
with some hyperlinks to provide further how to get started okay okay in that
45:07
case I would just use this example it used to be Auto DevOps demo
45:16
but in this case I will use them all for CI/CD only
45:27
I will add a new file on a new feature branch maybe not add a new file I just
45:33
modify a file on a new feature branch
45:39
and then we'll have a Merge Request so you see how the pipeline is running
45:45
We will see a definition file as well
45:50
and in that process we can also see the Review Apps so this Ruby application.
45:57
Let me take the look now... Can you quickly
46:05
explain what Auto DevOps is? I think we mentioned little bit earlier that
46:11
Auto DevOps is a feature of GitLab. It can be take your software code, it
46:18
can run a build automatically, run a test,
46:24
to run all the security scans, dependency scans, license scans, do
46:30
performance testing all these do all these automatic for you
46:35
we even without a CI definition file. So this is an existing one
46:41
it does not have a CI definition file but it does have a Dockerfile because when
46:47
you have the Dockerfile it will be faster. Without that it will do the
46:50
detection, so this is Auto DevOps but it
46:58
does support a CI definition file so in this demo I will show you that...
47:03
well, so this our latest for web IDE if you haven't heard. If you have it will be
47:12
very handy for you it's just like a clam it's just like a big clam
47:21
like a small clam but it's in a web browser. So for example if
47:27
I want to modify the CI definition file of Auto DevOps
47:35
modify Auto DevOps template, what I can do is do: CI
47:40
YAML file, choose a Auto DevOps template, load the Auto DevOps template, so this is number one
47:48
Number two I want it but I think I want to...
47:53
I wanted to show you before the... let me turn off
48:04
the notification so environment, the production environment, shows as I know
48:18
it's hollow single no because I think this one I need to do a redeployment
48:26
let me do these while it's running - redeploy - then we can make changes so this is our
48:36
CI definition file. For example if I want to leave some comments
48:43
here - add comment - and I know what to change, its about here is our web
49:01
content to be shown on our website let me see if this has been redeployed it's
49:12
running a CI job this one I think it's redeployed let me go back
49:28
take a look I think this should work
49:36
uh-huh what happened anyway let's proceed
49:44
to these. So basically we want to make a change to the website this is the place
49:50
we need to make change like like "Demo in a webcast"
50:06
okay so in that thing it's very common you want to stage
50:13
stage them, than you commit. now if I click commit it
50:19
will ask me to stage, because I have nothing, now nothing is in the stage
50:27
if I want to stage both, add this and add this as well, then I
50:40
don't want to commit to master directly I want it to go through
50:45
merge request. So this is the commit message. If you don't have anything I
50:51
will just use this, this is the default one and again is the new branch and merge request
50:58
requires if I click these so I'll ask me to provide a merge request title it
51:09
does include something default but I don't like it, like "Make web page changes"
51:24
maybe "Make text to change on web page" all right whatever description you want
51:35
to, so I don't need I just disable the merge request approval to
51:41
make the process faster now I got a merge request created, you can see
51:55
a pipeline is running on my personal kind of a feature branch
52:02
So this something we call mini pipeline graph
52:09
it runs a few stages, not all the stages that I mentioned and not all the scans I
52:16
mentioned because what I did I disabled some of them here
52:25
the only reason is those stages like called quality does
52:31
our container scanning the unit eight much longer time, it's let us now fit my
52:37
demo time so I disable them if you want to have all of them oh you just don't
52:44
specify any of them. This is one feature I like very much is you can use you can
52:52
you can stay here you don't need to use a back or forward you can just click the
52:59
links on a page for example I want to see all the details here so here it's
53:04
the pipeline UI you can see all these details like the "Build" stage just passed and
53:11
"Test" each has three jobs in parallel and all of them finished and it
53:19
is now advanced to "Review". This is a "Review" stage and the "Review" job.
53:28
This the job to create a review app. If we click this you can see
53:33
all the details it's automatically scroled, and it's just done, it's just done. There
53:41
are a few ways like I said a few ways to view that review app so if you want to go
53:47
back to the merge request we can click here there should be our review yes it's
53:56
the link this is a new link of the review apps I hope we can work
54:02
okay I think this works well, "Demo in a webcast" it's not "Hello world!", right? This
54:09
is our review app so at this moment you can ask some on
54:16
the host to do the code review and leave
54:23
comments to you so here are comments to you and now it's doing performance testing
54:29
if you want to wait until performance is done it's fine or if you think the security
54:35
performance index they'll be just for reference now
54:41
you can proceed to merge, to merge this so if you have merge request approval
54:49
on then you need somewhere else to review all your changes then to comment
54:55
to approve, okay, once I click this, "Merge" the code will run on
55:11
the server itself and here you can see the merge has been done so what will
55:18
happen because there's a new commit, the merge commit, on your
55:24
master branch then a pipeline will be running on your master branch. So this is the
55:30
new pipeline, it's the pipeline on master branch and you can see now here it's not
55:39
deploying - it's not deploying to a review environment because it's on master.
55:46
It's deployed to "Staging" directly, then manually you can deploy to "Production"
55:52
then run "Performance". So why this happens because we have a definition here
55:59
just go back to the merge request because we have we
56:05
have the CI definition file defined let's go to the review, let's
56:16
go to the review job, here is my review, here's my review job. You can see here it
56:26
will run only if it's on branch, only on a branch only have Kubernetes
56:35
integration active, means it has someplace to deploy and it's not on
56:42
master it's not disabled so this is why this job runs on feature branch only
56:51
not master branch only or if you want to take a look for "Staging"
56:57
it only runs on master, canary or production they only run on master so
57:04
this is the wait and this the condition that you can have only
57:09
except, so this part like Kubernetes integration
57:17
like some specific refs or like only respond to web push, web hook or trigger
57:25
all except under what kind of condition it will not work so variables
57:32
can be used all variables with regular expression also spotty it's also spotty
57:39
those are all the new features let me go back I still want to
57:46
take a look here see what happens to the master branch so it's almost there it's
57:55
deployed to the staging environment there are quite a few ways so for
58:02
example and this is great if I'll go to staging environment I can
58:11
create these ... so these it's the staging environment you can see
58:19
our environment is also versioned, it has its own history we
58:26
have all this history and if you want to take a look how does it look like
58:30
it's not finished sometimes they have trouble with the certificate in these..
58:41
what I can do let me do this let me give I'll retry off deployment you will run
58:46
the process again for that for the run we'd run a deployment job again I hope
58:56
it's not something related to the upgrade which has been done last week so
59:09
another place that you can see all these is environment so now if you have
59:25
multiple you have your own impression, you could see the progress here so
59:30
staging - let me try again - it's more problems of the certificate. Interesting this
59:38
still not working I need to find out what is the problem because it's something
59:47
very tricky so suppose it's running it's fine what I
59:53
can do is I roll out hundred percent then the roll out per job
60:01
it will be running for production - it's interesting - so if you
60:10
want to take a look what is happening I can go back pipelines
60:23
this is the job for production rollout its deploying again so I hope you can
60:34
see the progress here this is code deploy board
60:43
here is stil,l you can see, still running an old commit so this the benefit of a
60:49
environment, definition of concept environment you can do all these it's a survival
60:58
equation, it's on Kubernetes, you can have the monitoring, you can have
61:05
the interactive terminal, you can do the redeployment
61:13
so it sounds like it's done, let me do reload it must be someone redefine let
61:29
me see ah this one is working okay you know why this kid for staging is not
61:37
working things is working we can see more we can see more it's about the
61:42
monitoring keep this a few seconds these are all.. just show up so
61:53
if you have the Kubernetes integration and deploy your application to
61:59
Kubernetes cluster all these metrics will be provided but you don't
62:03
need to configure all of them but we do spot customer index if you want
62:09
here it's it's all provided by default
62:16
so that that is a circle so from our code change from feature branch until
62:22
everything is deployed and can reflect it in the production environment oh we
62:30
need to figure out why this was not working but basically it's a certificate problem
62:37
maybe we integrate with less ... maybe we just requested too many cerificates
62:44
at a time I guess I'm not quite sure we need to figure out that paper yeah okay
62:50
okay thank you very much the time is almost over so I was yet we spend
62:55
another few minutes to learn a little bit how to get started with GitLab CI.
63:01
okay cool like I said there's a web page this little web page "gitlab ci get started"
63:08
I hope the first one is the link yes "Getting started with CitLab CI/CD" oh we
63:16
have quite a few contents here on this page but I wouldn't say you need to read
63:23
all of them so click start this was what I said so you need two
63:32
things: number one CI YAML file, number two
63:36
configure a runner. to configure a runner I think
63:42
there are a lot of ways. Let's talk about the CI definition
63:47
file, so what is this CI definition? It is the process, right, now in this file you
63:52
have stages, you have "before scripts", so we have I think we have a detailed
64:00
description of CI definition file. By default
64:06
this file should be under the root directory of your project but like I
64:11
said we do have alternative of these you can define that here you can define
64:17
that here, not here, sorry, you can define here
64:39
you could define here "Custom CI config path".
64:47
So once you have all these now you need to configure a runner. Configure a
64:53
runner so there are two steps number one to install one, number two is to
64:59
configure one but if you don't want to play with the installation or configuration
65:04
or you don't have a resource there then you can try on gitlab.com, since
65:11
even free users have access to our shared free runners, so you
65:19
can play with that on gitlab.com so if you want to run something in your
65:26
own environment the number one the first step is to install it, like I
65:32
said we have a few..., we support all the major platforms you just need to go to
65:40
the runner web page to install it and after that to configure it so there are
65:46
one two three ways. If you are GitLab instance admin you can find the
65:55
token and install shared runner to your instance and
66:05
made it available to all projects on your instance or you can register it as a
66:11
project specific one or a group runner.
66:16
So installation is the first thing it's just a software install.
66:21
Registration is the connection, it establishes the connection between your runner
66:27
and your GitLab project or GitLab group or GitLab instance
66:34
So number one and number two, they are both necessary, so once you do all these
66:40
once you do all these and that's that for you is just to push out code to your
66:48
repository then a pipeline will be triggered
66:52
Just these very simple steps so two steps in
67:01
general: CI definition file and runner. So in runner also two steps: number one
67:08
install, number two is register. Register means a connection, establishing the
67:14
connection. There are further advanced topics of GitLab CI/CD, like how you can
67:22
use tag, how you can use conditions and how you can play more
67:31
which the advanced features, how can use it to publish artifacts, how
67:38
you can retrieve artifacts, how you can use caching, so those may not be cannot
67:45
be covered in a few minutes. Yes we have one or two hours training.
67:51
yeah so maybe maybe I'm doing confusion okay okay
67:58
thank you very much Xiaogang and thank you all of you for joining us and I
68:03
hope you could find it beneficial and relevant and interesting so just to wrap
68:09
up if you have any questions about GitLab if it's technical or if
68:13
you have question about pricing what edition is most suitable for you you can
68:19
contact us at gitlab@almtoolbox.com and our website
68:25
almtoolbox.com and of course the GitLab website GitLab.com so thank you very
68:30
much and have a nice day bye bye