33장. Merge requests - Using branches

 

 

## 목적 : 배포는 master 브랜치만 설정

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

  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

  script:

    - grep -q "Gatsby" ./public/index.html

test website:

  stage: test

  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"

 

 

## Gitlab으로 가서 feature/new-title 브랜치 생성

 

- 자동 파이프라인 생성

 

 

 

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Gitflow Workflow | Atlassian Git Tutorial

 

https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic

Keyword reference for the `.gitlab-ci.yml` file | GitLab

 

 

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

 

This later, we're going to take a look on how you can use much request and branches in order to improve

your overall kit workflow when using catalepsy.

Working with the branches is a good way of avoiding a master branch that cannot be deployed.

And we have seen previously that whenever a developer goes into a monster branch and makes a change,

a simple example was removing an import that the entire muther branch is no longer deployable.

And this is, of course, very unfortunate and it really can affect the entire work.

So the idea of working with branches is that each developer or each new feature can be deployed to a

specific branch, can be tested, and when it's ready for March, it can be merged into master back

and it can then be deployed on production.

And using this workflow really makes it much easier and guarantees that the master branch is always

deployable and this is actually part of continuous deployment.

You want to be able all the time to deploy your software.

And if the master branch isn't working because somebody has made a small mistake and everything stops

working, then this is not really going into the direction of continuous deployment and continuous delivery.

Now, there are different strategies, also known as branching models for dealing with the situation.

Gitlow is one example of them, but I will not go into details.

It's totally up to you how you want to do it and which workflow better suits your own organization.

But I would generally advise against only using the master for this.

Of course, you can make it much simpler.

Not every feature, not every bug needs to go to a specific branch.

It can be fairly easy.

Separate your workflows in a develop and in a master branch.

In develop is like the developing workflow you can break to develop and you can later fix it.

That would not be a problem and only when you're ready to make a release, you can merge all your changes

from the developer branched master.

But this is a bit a different workflow from what I wanted to show you.

I just wanted to show you a workflow where you can do as much request branches and sort of on each feature

goes into a branch.

Before we can use branches, there are a couple of things that we need to fix about our pipeline now

by default, what will happen is that if we create a new branch and push it, this pipeline will be

executed for that specific branch as well.

Now, generally, they are a couple of steps where it makes sense to execute a pipeline.

So, for example, we want to build an artifact.

We still want to build an artifact, and we still want to test if that artifact works.

And we still want to locally start the website to see if the website works.

But we definitely do not want to deploy to staging or to production from our branch or to run production

tests or something like that.

So this area here is definitely something that we do not want to do inside a branch.

And luckily, we can configure that.

We can specify that these three jobs will only be executed on M..

And this is quite easy.

I'll show you.

So by using only, we can set this policy to follow a specific rule.

So we're going to say only master.

And this will make this job only execute on Mr..

The thing we're going to do for deployed to production.

And for the production tests.

So let's now committee's changes, and after that, we're going to create the branch.

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 for 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.