37장. Dynamic environments

 

## Deploy Review Job 추가 생성
- Branch 에서 소스변경 (feature/oky)
- Master 로 Merge Requests 클릭

 

 

 

 

 

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

  script:

    - npm install --global surge

    - surge --project ./public --domain aido-$CI_ENVIRONMENT_SLUG.surge.sh

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"

 

 

 

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

 

It seems now that we can work with magic quests and we branches, but still we only have two environments

we have to staging and we have to production.

And the question is, wouldn't it be nice to have, like for each branch, for each future, a way to

view the changes that we have made on an actual system?

And this is actually possible we can create environments for every much request so we can automatically

spin up a dynamic environment for each much request.

And this allows us to review the changes on an actual system.

And if needed, we can run some more advanced tests if we want to be pretty similar to what we have

done on production, where we have the server, it's running and then we can check always everything

integrating well, does everything look good?

And this is not only a good thing for developers, but it can be quite valuable for testers or product

owners, product managers or anybody interested.

And seeing how the new future looks like maybe it's not a small fix, maybe it is a much larger feature,

and for that reason it will be nice to send somebody a link and say, hey, this is what I've been working

on.

This is the latest version.

Go on to this address and take a look and let me know what you like, how this works for you if everything

is OK.

So a non developer would be able to inspect the work that somebody has done by visiting an address and

not having to download code and compiling stuff and starting servers locally.

And this can be very convenient.

And this is exactly what we are going to do in this lecture.

We are gonna spin up a dynamic environment for every which request that we have.

So in order to do that, let's see if we need an additional state and probably we do.

So let's call this system review.

So we are trying to review the changes that we are doing.

So going to call this deploy review.

And that's at a new job.

This will be the same job name as the stage.

And what are we trying to do?

Well, it's pretty simple, what we are actually trying to do is pretty similar to what we have here.

We are trying to deploy something, too.

So what we are trying to do is do you a search in order to deploy whatever we have.

And we're going to change this a bit.

But for the moment, it's quite nice as we have it.

We only want to do it for my request so I can remove myself from here, so this will be only available

for each and every budget request.

And additionally, we need to specify the environment.

Now, the way I would do it is like this we're specifying the environment and the name of the environment

will be review slash and this is an environment variable that is provided by Gottleib.

And you will soon see how it looks like and the address that we are going to use is in the zone and

this is, uh, your Eleni's variable that we can use.

So I think we almost have everything that we need.

We still need to put this information here so to properly deploy.

And we should actually have everything in order to create this environment on the fly.

Now, you'll notice here because in the name we are using variables and no longer hard coding stuff,

it will automatically pick up this value.

And for each branch that we create, it will create a new environment.

And search here will deploy to that environment, so I'm going to create a new branch and push the changes

to the branch and we quickly take a look at how that works.

We now have extended the pipeline for the branches and for the merger request, and what we can see

is that dynamic environment has been created.

Now, the name of this environment is review slash feature dynamic environments, because this is the

way I have known my branch and we can view the app.

So the website that we have created.

So this is the address of the website that we have now is the zone dash review, dash feature and then

some strings.

And this is automatically dynamic.

So we haven't configured this specific address.

We have just used the variables and.

What happened is that we now have this dynamic environment, we can sell it to somebody or anybody looking

at this specific feature can simply take a look.

Hey, how does this look like?

Oh, interesting.

And can take a look up to code and see what we have changed and everything and can especially make comments

review.

Hey, why did you write that this look good, this looks bad, can give it a thumbs up for example,

and eventually can go into merging and lifecycle of this branch and some.

This is something very cool that we have achieved in this lecture now, our deployment process is still

very simple, but it's very, very nice to see how we can take advantage of this environment.

Holwell to integrate and get MCI and how we can see what we are doing.

We are taking everything.

We are creating dynamic environments for each of these branches.

And this is very, very nice.

And as you have seen, the configuration isn't that hard to understand.

So it's quite, quite easy to follow what's going on and how everything works.