36장. 병합 요청 - 첫 번째 병합 요청

 

 

## Feature/new title 브랜치에서 소스코드 수정 후, maser로 merge 수행 -> 빌드후, 웹배포 성공
- 배포 성공 후, Feature/new title 브랜치는 자동 삭제

 

 

 

 

 

 

## .gitlab-ci.yml

image: node

stages:

  - build

  - test

  - 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 staging:

  stage: deploy staging

  environment:

    name: staging

    url: http://$STAGING_DOMAIN

  only:

    - master

  script:

    - npm install --global surge

    - surge --project ./public --domain $STAGING_DOMAIN

deploy production:

  stage: deploy production

  environment:

    name: production

    url: http://$PRODUCTION_DOMAIN

  only:

    - master  

  # when: manual

  # allow_failure: false

  script:

    - npm install --global surge

    - surge --project ./public --domain $PRODUCTION_DOMAIN

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"

 

 

 

 

 

 

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

 

I am going back to get Lamp and I want to create a new branch.

Of course you can do it anywhere you want, but it will be much easier to demonstrate it from here.

I'll go to repository branches.

They're going to select new branch.

Let's say that we want to add a different title to our website and name it feature.

Your title.

And I'm going to create this branch from MOSTRO.

As soon as I've created this brunch, the pipeline will start.

And you will see that the pipeline itself is much shorter, so we don't only build a website and then

go to testing and if everything looks good, then we can say we are ready to march this branch back

into the master.

Now, let's actually go ahead and make a small change inside a website.

So I am inside source pages, index chairs, and I'm going to make a small change to this process.

And I have added here a new title in committees.

And.

And now let's go ahead and create our first budget request.

If I want, I can put in a description, maybe telling a bit more why this is needed and why I'm doing

this.

And if I'm doing more commits, working continuously, working on this branch, there are a couple of

things that I can check as well.

So first of all, I can delete my branch once the merge request accepted.

And this will be very helpful, especially.

Because you will not have branches which have no reference anymore, which you don't need, basically.

I'm going to click submit my request.

So now we're much request looks like this, you will see here that a pipeline is running and it's still

building, we can click here March one pipeline succeeds and the entire pipeline will be marched.

So let's go ahead and click on it.

And this will be automatically merged when the pipeline succeeds.

So as soon as this final test job is done, we to test this Getler lab will automatically march this

branch for us and to sort of branch that we had will be deleted.

You know, the pipeline was successful and what exactly is happening is that the changes were to master

and now the pipeline for the master branch has started it up.

Now, because we are using environment has even detected what will be deployed and it forces will deploy

to staging, will deploy to production and even have the possibility of stopping a deploying.

So if you're saying, oh, wait a minute, what are you doing?

Want to deploy this production?

Simply click here and it will not be deployed to production and you get this link.

So the integration and everything that is available with environment is quite interesting and very,

very intuitive.

It seems that the Mustapa plan worked pretty well because we have deployed on staging and production

as well.

And let's quickly click on VoIP so that we can inspect the changes that have been made.

You will see in the near future that they have implemented this is a new title is perfectly displaying

here.

So in this lecture, we have introduced a new workflow for dealing with features or bug fixes, and

now we are actually capable of using branches in order to work in our environment and to make sure that

what we have in master is a bit better tested and that we don't break the master just this easy and

that we cannot push for any changes into the master without going through this simple review process

that we have in place right now.