46장. ​​작업 템플릿 만들기

 

## .deploy_template 생성 후,
- deploy staging, deploy production 상속

 

 

## .gitlab-ci.yml

image: node

stages: 
  - build
  - test
  - deploy review
  - deploy staging
  - deploy production
  - production tests

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

variables:
  STAGING_DOMAIN: aido-stg.surge.sh
  PRODUCTION_DOMAIN: aido-pro.surge.sh

build website:
  stage: build
  only:
    - master
    - merge_requests  
  script:
    - echo $CI_COMMIT_SHORT_SHA
    - npm install
    - npm install -g gatsby-cli
    - gatsby build
    - sed -i "s/%%VERSION%%/$CI_COMMIT_SHORT_SHA/" ./public/index.html
  artifacts:
    paths:
      - ./public

test artifact:
  image: alpine
  stage: test
  only:
    - master
    - merge_requests
  script:
    - grep -q "Gatsby" ./public/index.html

test website:
  stage: test
  only:
    - master
    - merge_requests
  script:
    - npm install
    - npm install -g gatsby-cli
    - gatsby serve &
    - sleep 3
    - curl "http://localhost:9000" | tac | tac | grep -q "Gatsby"

deploy review:
  stage: deploy review
  only:
    - merge_requests
  environment:
      name: review/$CI_COMMIT_REF_NAME
      url: https://aido-$CI_ENVIRONMENT_SLUG.surge.sh
      on_stop: stop review      
  script:
    - npm install --global surge
    - surge --project ./public --domain aido-$CI_ENVIRONMENT_SLUG.surge.sh

stop review:
  stage: deploy review
  only:
    - merge_requests
  variables:
    GIT_STRATEGY: none
  script:
    - npm install --global surge
    - surge teardown aido-$CI_ENVIRONMENT_SLUG.surge.sh
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop

.deploy_template: &deploy
  only:
    - master
  script:
    - npm install --global surge
    - surge --project ./public --domain $DOMAIN
  environment:
    url: http://$DOMAIN


deploy staging:
  <<: *deploy
  stage: deploy staging
  variables:
    DOMAIN: $STAGING_DOMAIN
  environment:
    name: staging


deploy production:
  <<: *deploy
  stage: deploy production
  variables:
    DOMAIN: $PRODUCTION_DOMAIN  
  environment:
    name: production
  # when: manual
  # allow_failure: false

production tests:
  image: alpine
  stage: production tests
  only:
    - master
  script:
    - apk add --no-cache curl
    - curl -s "https://$PRODUCTION_DOMAIN" | grep -q "Hi people"
    - curl -s "https://$PRODUCTION_DOMAIN" | grep -q "$CI_COMMIT_SHORT_SHA"

 

 

 

## YAML 문법 확인 --> CI lint

 

 

 

 

 

 

 

 

 

 

================================================

 

This lecture, we're going to take a look at how we can use the anchors from the Yamal language and

apply that information to our digital IPSI pipeline.

Now, if we take a closer look at our pipeline, we will see that we have a few jobs that aren't, in

essence, quite similar.

And from all jobs that we have deployed, job is more or less duplicated.

So from all the jobs that we have, the deployed job, we have three instances.

So we are deploying to the review server, we are deploying to the staging and we're deploying to production.

And even if we simply compare, deploy staging and deploy production, we'll see that they are very,

very similar.

So what you will do is to try to find like what's similar in all this jobs and to extract that information

to make the job much simpler.

In this example.

That application isn't that bad, but.

In other more complex project, you can end up with job definitions, which are very similar, very

long, and it doesn't make a lot of sense to make a change all over just because something is change.

So let's try to extract specific information.

So we'll do the following.

Let's try and see if we can define a template.

I'm going to call it deploy.

This comtemplate.

You won't see that by using the dot before it, this is disabled, so this will not be taken into consideration

by Guillem.

Now, let's take a look at both and see, which is similar to, for example, we have here this only

configuration, which for both is the same.

So we can start moving that.

Additionally, if we look at a script itself, we'll see that that is pretty similar as well.

There's only a small difference.

This is using staging domain and this is using production domain.

But I'm pretty sure that will be able to find a way around this.

So I got to move this year.

And instead of staging domain or production domain, let's just simply call it domain.

Now, there's one more thing that we still need to do, first of all, we need to find a way to define

these variables.

So let's go here, create a variable configuration.

And when we find a variable domain.

And in this case, in the case of staging to take the value from staging domain.

And if we look at production, we can use.

Reduction.

And if we go one step further and replace.

This information from here, from the environment, we can see that even the environment is not that

different.

So let's copy the environment as well.

Because we want to remove this key from here, because this is something that we cannot know.

But apart from that, looks pretty good now in order to use this template inside our job configurations,

we need to refer to this anchor and we haven't defined an anchor yet.

So let's define this anchor.

Let's call it deploy.

And in order to use the anchor.

We're going to use it like that, and what this will do is to march this new configuration into one.

But this is for the police.

This is for.

Deploy production.

The next step will be to take this configuration that we have here and try to validate it.

So I'm going to select it and I'm going to copy it.

Now, I'm here at krp, at my project, and I'm going to go from the left menu to secede.

Right here on top, you should notice a button called Silent.

This tool helps us verify our catalepsy lapse YAML file, and this is especially useful if something

doesn't work or before committing, if we are not sure that what we have done there is actually valid.

Well, A simply pays the content here and a click on Validate.

You will see that I will have an error saying Syntex is incorrect and will say a specific error, and

that's quite helpful because I can then have a look at the line that is being indicated 102.

And I'll be able to see that in this case, I haven't I don't have the right indentation for variables,

so this is not correct.

So if I make now the correct indentation, let's see if it works.

And it says Syntex is correct.

Not what I actually wanted to see if this configuration, if this template that we have used here has

been properly picked up.

So if we take a look at the deploy staging job, we should see a couple of things which would see that

only master has been set.

The script has been said.

So let's go to deploy staging.

Now, what this does is list all the jobs that are here and it explains what Gottleib has understood

from this.

So this is the staging.

You will see here that we still have NPM install installing surge.

This is actually a display problem that Gottleib is having.

This is the other command that we have where we are actually deploying to search.

So at least from what we see here, it seems to be working properly and this configuration has been

correctly being picked up.

So I'm confident now that I can commit it.

And let's see, it's on in action.

I have now created a request and I have merged that specific branch and now the pipeline for Master

has been started and completed successfully.

Now I can see that the staging and production work without any issues.

And if I'm just interested in seeing if everything actually worked well, I can simply go inside a job

and see that all the steps and all the stages, as they were before, have been used, that the proper

domain name has been used and that everything has been properly deployed.

So using this technique, you can go ahead and do the next step on your own, so we have defined this

template deploy template and we have used it for the staging and deployed production actually deploy

review is quite similar.

And I wanted to give you the opportunity to try it on your own so that you can get some real world experience

on adapting this to make sure that all the deploy stages now use this template.

And as you have seen, even this configuration is pretty simple.

It is nice now to have a central way where you can optimize or change this code without having to update

each and every of these environments or each of these jobs that you have there.