Gitlab → Github 마이그레이션 후기 ( ci/cd )

Gitlab? GitHub? 그게 뭐지 ?

깃랩, 깃헙은 쉽게 말해서 코드관리 툴 입니다! 프로그램코드를 저장하고 배포할 수 있는 역할을 합니다 !

유지보수, 크리틱 이슈등을 여기서 보고 처리합니다! 코드를 개발하고 그 개발한 것을 description을 붙혀서 올리면 다른 분들이 보기도 편하고 수정하기도 편하기 때문에 거의 모든 개발자가 쓴다고 해도 과언이 아닐만큼 많이 사용됩니다!

ci/cd

완전 테크적인 설명 ( 아래 쉬운 설명도 있습니다)

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬(integration hell)")을 해결하기 위한 솔루션입니다.

특히, CI/CD는 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐 지속적인 자동화와 지속적인 모니터링을 제공합니다. 이러한 구축 사례를 일반적으로 "CI/CD 파이프라인"이라 부르며 개발 및 운영팀의 애자일 방식 협력을 통해 지원됩니다.

CI와 CD(및 또 다른 CD)의 차이점은 무엇일까요?

CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있습니다. CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.

CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.

지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 줍니다. 지속적인 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 합니다.

지속적인 배포(또 다른 의미의 "CD": Continuous Deployment)란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용합니다.

CI/CD는 지속적 통합 및 지속적 제공(CD, Continuous Delivery)의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있습니다. 좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 합니다.

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미합니다. 이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라집니다. 대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나갑니다.

지속적 통합

현대적인 애플리케이션 개발에서는 여러 개발자들이 동일한 애플리케이션의 각기 다른 기능을 동시에 작업할 수 있도록 하는 것을 목표로 합니다. 그러나 조직에서 특정한 날("[병합(머지)하는 날(merge day)](https://thedailywtf.com/articles/Happy_Merge_Day!)")을 정해 모든 분기 소스 코드를 병합하는 경우, 결과적으로 반복적인 수작업에 많은 시간을 소모하게 됩니다. 이렇게 반복적인 수작업을 하는 이유는 독립적으로 작업하는 개발자가 애플리케이션에 변경 사항을 적용할 때 다른 개발자가 동시에 적용하는 변경 사항과 충돌할 가능성이 있기 때문입니다. 이는 팀이 하나의 클라우드 기반 통합 개발 환경(Integrated Development Environment, IDE) 사용에 동의하는 대신 각 개발자가 각자의 로컬 IDE를 커스터마이징하는 경우 더욱 복합적인 문제가 될 수 있습니다.

CI(지속적 통합)를 통해 개발자들은 코드 변경 사항을 공유 브랜치 또는 "트렁크"로 다시 병합하는 작업을 더욱 수월하게 자주 수행할 수 있습니다. 개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인합니다. 다시 말해, 클래스와 기능에서부터 전체 애플리케이션을 구성하는 서로 다른 모듈에 이르기까지 모든 것에 대한 테스트를 수행합니다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 자주 수정할 수 있습니다.

지속적 제공

CI의 빌드 자동화, 유닛 및 통합 테스트 수행 후, 이어지는 지속적 제공(CD, Continuous Delivery) 프로세스에서는 유효한 코드를 리포지토리에 자동으로 릴리스합니다. 그러므로 효과적인 지속적 제공 프로세스를 실현하기 위해서는 개발 파이프라인에 CI가 먼저 구축되어 있어야 합니다. 지속적 제공의 목표는 프로덕션 환경으로 배포할 준비가 되어 있는 코드베이스를 확보하는 것입니다.

지속적 제공의 경우, 코드 변경 사항 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계에는 테스트 자동화와 코드 릴리스 자동화가 포함됩니다. 이 프로세스를 완료하면 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포할 수 있게 됩니다.

지속적 배포

CI/CD 파이프라인의 마지막 단계는 지속적 배포입니다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화합니다. 프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 합니다.

실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다(자동화된 테스트를 통과한 것으로 간주). 이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해집니다. 이러한 모든 CI/CD 적용 사례는 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있습니다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요합니다.

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정

쉬운설명

개발자가 코드를 서버에 배포하는 방식을 더 쉽게 해주는 코드들입니다!

예를들면 프론트엔드 코드 작성 → 백엔드 서버 전달 ( 클라우드서버이거나 실제 리눅스 서버등 ) → 개발자가 서버에 직접 올려야함 → 서버에 올리는 것 까지 확인해야함

이였던 과정을

프론트엔드 코드 작성 → 서버올림 으로 줄여줍니다. 두둥..

하지만 장단점이 있습니다.

장점은 정말 편합니다. 실제 서버에 바로 올라가기 때문이죠 !

단점은 정말 조심해야합니다. 실제 서버에 바로 올라가기 때문이죠!

저는 gitlab ci/cd 에서 git action으로 ci/cd 으로 변경을 했습니다 ! 과정은 플로우만 알면 쉽게 건들일 수 있습니다 : )

Emotion

오늘은 Emotion에 대해 소개해드리겠습니다 !

Emotion의 장점 🌟

• css-in-js 형식으로 스타일을 사용할 수 있다.
• className이 자동으로 부여되기 때문에 스타일이 겹칠 염려가 없다.
• 재사용이 가능하다.
• props, 조건 등에 따라 스타일을 지정 가능하다.
• vendor-prefixing, nested selectors, and media queries 등이 적용되어 작성이 간편하다. ( 알기 쉽게 반응형 이라고 생각하시면 됩니다 :) )
• styled component 사용방식과 css prop 기능을 지원하여 확장에 용이하다. ( 앱에서는 styled component를 많이 사용하지만 웹에서는 prop 기능때문에 Emotion을 많이 사용하는 것 같습니다. 개발자 차이이지만 css, scss를 사용하거나 styled component, emotion등을 사용 하는 것은 개발자 차이입니다! )
• styled component보다 파일 사이즈가 작고, ssr시 서버 작업이 필요없다. ( ssr 이란 서버사이드 랜더링입니다!) 서버사이드랜더링 플로우 입니다

사용법 📘

css prop

import { css } from '@emotion/react'

const color = 'white'

render(
  <div
    css={css`
      padding: 32px;
      background-color: hotpink;
      font-size: 24px;
      border-radius: 4px;
      &:hover {
        color: ${color};
      }
    `}
  >
    Hover to change color.
  </div>
)

composition

import { css } from '@emotion/react'

const danger = css`
  color: red;
`const base = css`
  background-color: darkgreen;
  color: turquoise;
`render(
  <div>
    <div css={base}>This will be turquoise</div>
    <div css={[danger, base]}>
      This will be also be turquoise since the base styles
      overwrite the danger styles.
    </div>
    <div css={[base, danger]}>This will be red</div>
  </div>
)

styled component

import styled from '@emotion/styled'

const Button = styled.button`
  padding: 32px;
  background-color: hotpink;
  font-size: 24px;
  border-radius: 4px;
  color: black;
  font-weight: bold;
  margin-bottom: ${props => props.value ? '4px' : '2px'}
  &:hover {
    color: white;
  }
`render(<Button>This my button component.</Button>)

Object styles

import { jsx } from '@emotion/react'

render(
  <div
    css={{
      color: 'darkorchid',
      backgroundColor: 'lightgray'
    }}
  >
    This is darkorchid.
  </div>
)

import styled from '@emotion/styled'

const Button = styled.button(
  {
    color: 'darkorchid'
  },
  props => ({
    fontSize: props.fontSize
  })
)

render(
  <Button fontSize={16}>
    This is a darkorchid button.
  </Button>
)

Child Selectors

import { jsx } from '@emotion/react'

render(
  <div
    css={{
      color: 'darkorchid',
      '& .name': {
        color: 'orange'
      }
    }}
  >
    This is darkorchid.
    <div className="name">This is orange</div>
  </div>
)

media Queries

import { jsx } from '@emotion/react'

render(
  <div
    css={{
      color: 'darkorchid',
      '@media(min-width: 420px)': {
        color: 'orange'
      }
    }}
  >
    This is orange on a big screen and darkorchid on a small
    screen.
  </div>
)

Reusable Media Queries

import {  css } from '@emotion/react'

const breakpoints = [576, 768, 992, 1200]

const mq = breakpoints.map(
  bp => `@media (min-width: ${bp}px)`)

render(
  <div>
    <div
      css={{
        color: 'green',
        [mq[0]]: {
          color: 'gray'
        },
        [mq[1]]: {
          color: 'hotpink'
        }
      }}
    >
      Some text!
    </div>
    <p
      css={css`
        color: green;
        ${mq[0]} {
          color: gray;
        }
        ${mq[1]} {
          color: hotpink;
        }
      `}
    >
      Some other text!
    </p>
  </div>
)

numbers

import { jsx } from '@emotion/react'

render(
  <div
    css={{
      padding: 8,
      zIndex: 200
    }}
  >
    This has 8px of padding and a z-index of 200.
  </div>
)

fecepaint

npm i facepaint

import { jsx } from '@emotion/react'
import facepaint from 'facepaint'

const breakpoints = [576, 768, 992, 1200]

const mq = facepaint(
  breakpoints.map(bp => `@media (min-width: ${bp}px)`)
)

render(
  <div
    css={mq({
      color: ['green', 'gray', 'hotpink']
    })}
  >
    Some text.
  </div>
)

내가 느낀 장, 단점 😎

장점

혼자 프론트엔드를 개발하고 스타일을 주려면 Emotion을 쓰는 것이 훨씬 편할 겁니다. 왜냐하면 엘리멘트 태그들을 자기 마음대로 커스터마이징 할 수 있고 자기가 작성한 태그니까 알기가 쉬울 것 이라고 생각합니다 🙂

단점

다른 개발자 분이 코드를 봤을 때 2번 일을 해야하는 경우가 있을 수 있습니다. div라는 태그를 바꾸고 싶은데 실제 퍼블리싱 코드에는 div가 없어서 div emotion 코드를 찾아서 변경을 해줘야하는 부분이 단점? 불편한점 이라고 생각합니다. 그리고 엘리먼트 태그들은 많아질 수록 가독성이 떨어진다는 부분이 저에게는 단점으로 느껴졌습니다. 😢

결론

일단은 Emotion으로 되어있는 코드들을 보고 유지보수에 최대한 힘을 쓰는 것이 첫 번째 라고 생각합니다. 물론 다른 스타일 라이브러리나 css 등은 보기 쉽겠지만 조금은 더 시간을 들여야 하지 않나, 이 시간을 최대한 줄이자 라는 마음으로 개발해야 할 것 같습니다. 그리고 조금씩 익숙해지면 바로바로 적응이 가능할 것 같습니다 😊

Recoil

recoil이란 mobx → redux → recoil 순서대로 페이스북에서 만든 상태 관리 라이브러리이다.angular같은 경우 부모 컴포넌트에서 자식 컴포넌트 사이의 props를 주고받기 편하게 되어있다.주고 받을 수는 있지만 코드가 굉장히 복잡해지고 어디서 어떤 data를 받았는지, 내려줬는지 일일히 다 체크해야한다. 그래서 이 문제를 해결하기위해 상태 관리 라이브러리가 나왔다.

그림1)

첫번째 그림은 최상단 컴포넌트가 X 내려받을 컴포넌트가 Y 라고 가정했을 때

X → Y 로 데이터가 전달 되려면 저렇게 내리고 내리고 내리고... 해야 값을 받을 수 있다

그림2)

하지만 두 번째의 네모 역할이 상태 관리 라이브러리이다. 장바구니, 샵 이라고도 많이 불린다.

필요한 data를 저곳에 넣어 놓고 어디서든 꺼내서 사용하면 된다.

위에 예시는 간단한 구조라 쉽겠지만 트리구조가 길어지면 복잡해져서 거의 99%는 상태 관리 라이브러리를 사용한다고 생각한다. ( 글쓴이의 생각 )

그럼이제 recoil을 알아보자.

Installation

CRA(npx create-react-app)로 리액트 파일을 생성한 후 아래 cli로 리코일을 설치한다.

npm i recoil // or yarn add recoil

RecoilRoot

리코일 state를 사용하는 컴포넌트들은 <RecoilRoot>를 필요로 한다. <RecoilRoot>를 사용하는 가장 좋은곳은 root component이다.

// app.js
import React from 'react';
import {
  RecoilRoot,
  atom,
  selector,
  useRecoilState,
  useRecoilValue,
} from 'recoil';    // import!!! import하는것은 important하닌까 ~

function App() {
  return (
    <RecoilRoot>    // 이렇게 감싸주어야한다.
      <CharacterCounter />
    </RecoilRoot>
  );
}

Atom

아톰은 상태를 말하며 어떠한 컴포넌트에서 씌여지고 읽혀질 수 있다. 아톰의 va를 읽는 컴포넌트들은 암묵적으로 그 아톰에게 참고(subscribe)되어지고 있다. 그래서 아톰의 업데이트는 이 아톰을 참고하고 있는 컴포넌트를 리렌더 시킨다.

const textState = atom({
  key: 'textState', // unique ID (다른 atoms/selectors을 구별하기 위해서)
  default: '', // default value (aka initial value)
});

function CharacterCounter() {
  return (
    <div>
      <TextInput />
      <CharacterCount />
    </div>
  );
}

function TextInput() {
  const [text, setText] = useRecoilState(textState);

  const onChange = (event) => {
    setText(event.target.value);
  };

  return (
    <div>
      <input type="text" value={text} onChange={onChange} />
      <br />
      Echo: {text}
    </div>
  );
}

Selector

셀렉터는 하나의 추출된 state다. '추출된(derived 또는 파생된)'이라는 의미는 state가 변경(transformation)된것을 의미한다. 다시 말해서 추출된 상태란, 주어진 상태를 변경(modify)시키는 순수 함수에 의해서 변경된 스테이트(the output)라고 말할 수 있다.(실제 상태를 변경시키지는 않는거 같다.)

// usage
const charCountState = selector({
  key: 'charCountState', // unique ID (with respect to other atoms/selectors)
  get: ({get}) => {
    const text = get(textState);

    return text.length;
  },
});

function CharacterCount() {
  const count = useRecoilValue(charCountState);

  return <>Character Count: {count}</>;
}

간단하게

import React from 'react';
import countState from './Atoms';
import { useRecoilState,
  useRecoilValue,
  useSetRecoilState,
  useResetRecoilState
} from 'recoil';

function Counter() {
  const [counter, setCounter] = useRecoilState(countState);
  // useState와 같지만, useRecoilState을 사용하여 다른 파일에 있는 아톰을 읽을 수 있다.
  const currentCount = useRecoilValue(countState);  // 읽기 전용!
  const counterHandler = useSetRecoilState(countState); // 값만 변경 시키기
  const resetCounter = useResetRecoilState(countState); // 디폴트값으로 값 변경

이정도 명령어만 알고있으면 좋을 것 같다.

뒤에 useRecoilState, useRecoilValue useSetRecoilState, useResetRecoilState 정도 알고있자.

recoil은 정말 hooks에 잘 맞게 나온 상태 라이브러리 같다.

틀린부분이 있으면 피드백 주시면 감사하겠습니다 :)

undefined은 변수를 선언하고 값을 할당하지 않은 상태, null은 변수를 선언하고 빈 값을 할당한 상태(빈 객체)이다. 즉, undefined는 자료형이 없는 상태이다.
따라서 typeof를 통해 자료형을 확인해보면 null은 object로, undefined는 undefined가 출력되는 것을 확인할 수 있다.

typeof null // 'object'
typeof undefined // 'undefined'
null === undefined // false
null == undefined // true
null === null // true
null == null // true
!null // true
isNaN(1 + null) // false
isNaN(1 + undefined) // true

#undefined

undefined는 원시값(Primitive Type)으로, 선언한 후에 값을 할당하지 않은 변수나 값이 주어지지 않은 인수에 자동으로 할당된다. 이 값은 전역 객체의 속성 중 하나로, 전역 스코프에서의 변수이기도 하다. 따라서 undefined 변수의 초기 값은 undefined 원시 값이다.

cf) undefined는 예약어가 아니기 때문에, 전역 범위 외에서 변수 이름으로 사용할 수 있다. 그러나 유지보수와 디버깅에 어려움을 겪을 수 있으므로 피하는 것이 좋다.

아래의 경우에 변수가 undefined를 반환한다.

• 값을 할당하지 않은 변수
• 메서드와 선언에서 변수가 할당받지 않은 경우
• 함수가 값을 return 하지 않았을 때

#null

null은 원시값(Primitive Type) 중 하나로, 어떤 값이 의도적으로 비어있음을 표현한다. undefined는 값이 지정되지 않은 경우를 의미하지만, null의 경우에는 해당 변수가 어떤 객체도 가리키고 있지 않다는 것을 의미한다.

cf) null은 undefined처럼 전역 객체의 속성 중 하나가 아니라 리터럴 값이다.

#알아두면 좋은 것

• typeof undefined는 출력하면 undefined이다.
• typeof null은 출력하면 object이다. 하지만 이는 여전히 원시 타입(primitive value)로, JavaScript에서는 구현 버그로 간주한다.
• undefined == null은 true이다.

참조 : https://2ssue.github.io/common_questions_for_Web_Developer/docs/Javascript/13_undefined&null.html#undefinedhttps://2ssue.github.io/common_questions_for_Web_Developer/docs/Javascript/13_undefined&null.html#undefine