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 으로 변경을 했습니다 ! 과정은 플로우만 알면 쉽게 건들일 수 있습니다 : )

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

AJAX (Asynchronous Javascript And XML)

AJAX란, JavaScript의 라이브러리중 하나이며 Asynchronous Javascript And Xml(비동기식 자바스크립트와 xml)의 약자이다. 브라우저가 가지고있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법 이며 JavaScript를 사용한 비동기 통신, 클라이언트와 서버간에 XML 데이터를 주고받는 기술이다.

즉, 쉽게 말하자면 자바스크립트를 통해서 서버에 데이터를 요청하는 것이다.

비동기 방식이란 99geo.tistory.com/64

를 참고 하면 된다.

AJAX를 사용 가능하게 만드는 것들

AJAX라는 기술은 여러가지 기술이 혼합적으로 사용되어 이루어진다. 대표적인 예로는 아래와 같은 것들이 있다.

• HTML
• DOM
• JavaScript
• XMLHttpRequest
• Etc

AJAX로 할 수 있는 것

AJAX라는 네트워크 기술을 이용하여 클라이언트에서 서버로 데이터를 요청하고 그에 대한 결과를 돌려받을 수 있다.

간단하게 말하면 서버와 클라이언트(나)와의 통신이다

클라이언트란?

서버에서 정보를 가져와서 사용자에게 보여줄 수 있고 사용자와 상호작용할 수 있는 소프트웨어를 일컫는다.
Ex) 웹브라우저, 핸드폰 어플리케이션 등...

서버란?

네트워크 상에서 접근할 수 있는 프로그램으로서 어떤 자료들에 대한 관리나 접근을 제어해주는 프로그램을 말한다. 서버는 일반적으로 사용자가 직접적으로 사용하지 않는다.

AJAX를 사용하는 이유

단순하게 WEB화면에서 무언가 부르거나 데이터를 조회하고 싶을 경우, 페이지 전체를 새로고침하지 않기 위해 사용한다고 볼 수 있다.

기본적으로 HTTP 프로토콜은 클라이언트쪽에서 Request를 보내고 서버쪽에서 Response를 받으면 이어졌던 연결이 끊기게 되어있다. 그래서 화면의 내용을 갱신하기 위해서는 다시 request를 하고 response를 하며 페이지 전체를 갱신하게 된다. 하지만 이렇게 할 경우, 엄청난 자원낭비와 시간낭비를 초래하고 말 것이다.

AJAX는 HTML 페이지 전체가 아닌 일부분만 갱신할 수 있도록 XMLHttpRequest객체를 통해 서버에 request한다. 이 경우, JSON이나 XML형태로 필요한 데이터만 받아 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있다.

AJAX의 장단점

1. AJAX의 장점

• 웹페이지의 속도향상
• 서버의 처리가 완료될 때까지 기다리지 않고 처리가 가능하다.
• 서버에서 Data만 전송하면 되므로 전체적인 코딩의 양이 줄어든다.
• 기존 웹에서는 불가능했던 다양한 UI를 가능하게 해준다. ( Flickr의 경우, 사진의 제목이나 태그를 페이지의 리로드 없이 수정할 수 있다.)

2. AJAX의 단점

• 히스토리 관리가 되지 않는다.
• 페이지 이동없는 통신으로 인한 보안상의 문제가 있다.
• 연속으로 데이터를 요청하면 서버 부하가 증가할 수 있다.
• XMLHttpRequest를 통해 통신하는 경우, 사용자에게 아무런 진행 정보가 주어지지 않는다. (요청이 완료되지 않았는데 사용자가 페이지를 떠나거나 오작동할 우려가 발생하게 된다.)
• AJAX를 쓸 수 없는 브라우저에 대한 문제 이슈가 있다.
• HTTP 클라이언트의 기능이 한정되어 있다.
• 지원하는 Charset이 한정되어 있다.
• Script로 작성되므로 디버깅이 용이하지 않다.
• 동일-출처 정책으로 인하여 다른 도메인과는 통신이 불가능하다. (Cross-Domain문제)

AJAX의 진행과정

1. XMLHttpRequest Object를 만든다.
   • request를 보낼 준비를 브라우저에게 시키는 과정
   • 이것을 위해서 필요한 method를 갖춘 object가 필요함
2. callback 함수를 만든다.
   • 서버에서 response가 왔을 때 실행시키는 함수
   • HTML 페이지를 업데이트 함
3. Open a request
   • 서버에서 response가 왔을 때 실행시키는 함수
   • HTML 페이지를 업데이트 함
4. send the request

1. axios

• 구형 브라우저를 지원한다.
• 응답 시간 초과를 설정하는 방법이 있다.
• JSON 데이터 자동변환이 가능하다.
• node.js에서의 사용이 가능하다.
• request aborting(요청 취소)가 가능하다.
• catch에 걸렸을 때, .then을 실행하지 않고, console창에 해당 에러 로그를 보여준다.
• return값은 Promise 객체 형태이다.

2. fetch

• JavaScript의 내장 라이브러리이기 때문에 import 하지 않고 사용할 수 있다.
• 라이브러리의 업데이트에 따른 에러 방지가 가능하다.
  (React Native의 경우 업데이트가 잦아서 라이브러리가 쫓아오지 못하는 경우가 많은데, fetch의 경우 이를 방지할 수 있다.)
• 네트워크 에러가 발생했을 때 기다려야한다. (response timeout API 제공X)
• 지원하지 않는 브라우저가 있다.
• return값은 Promise 객체 형태이다.

이 두가지를 가장 많이 쓴다 상황에 따라 다르지만 필자의 경우 axios를 많이 쓴다.

각각 코드를 비교해보면

async function test() {
        await axios({
            method: 'get',
            url: `https://api.testUrl`
        }).then(function (response) {
            console.log("성공", response)
        }).catch(function (error) {
            console.log("실패", error)
        })

이런식으로 axios를 사용한다.

fetch(url, options)
  .then((response) => console.log("response:", response))
  .catch((error) => console.log("error:", error))

fetch는 이런식으로 사용합니다.

이둘의 차이점은 다음 포스팅에서 하겠습니다.

마지막 정리

Ajax - 서버와 클라이언트 통신

axios는 ajax등의 웹 통신 기능을 제공하는 라이브러리 (생각보다 헷갈리고 모르고 사용하는경우가 많음)

참고 문서 : velog.io/@surim014/AJAX%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

비동기 프로그래밍 ( Asynchronous ) ?

JavaScript 는 단일 스레드에서 동작합니다. => 한번에 한가지 일만 할 수 있습니다. ‘그럼 안 좋은거 아니야?’라고 생각할 수 있지만 싱글 스레드는 멀티 스레드가 겪어야 하는 골치 아픈 문제들을 신경 쓰지 않아도 된다는 장점이 있다.

싱글스레드만으로 멀티스레드 부럽지 않은 부드러운 소프트웨어를 만들기 위해서는 대가를 치뤄야 한다. 그 대가가 바로 비동기적(asynchronous) 프로그래밍이다.

- 하나의 요청 처리가 완료되기 전에 제어권을 다음 요청으로 넘겨 Blocking 되지 않으며 다음 요청을 처리 하는 방식. (ex. nodejs)

방식

콜백 방식

• 자바 스크립트에서 함수는 일급 객체이므로 파라미터로 넘길 수 있음.
  • 일급 객체란?
    • 변수나 데이터에 할당 가능.
    • 객체의 인자로 넘길수 있음.
    • 리턴값으로 사용 가능.
• 실행 결과를 보면 비동기로 수행되는것을 알수 있음.
• 위의 전달된 콜백 함수는 디렉토리를 모두 읽은 후 호출됨으로써 비동기 프로그래밍이 가능해짐.

let fs = require('fs');
 
console.log('start');
 
fs.readdir('.', (err, filenames) => {
  if (err) {
    console.error(err);
    return;
  }
  
  for (let i = 0; i < filenames.length; i++) {
    console.log(filenames[i]);
  }
});

console.log('end');
 
 
// 실행 결과: start -> end -> filenames

Promise 방식

• 복잡한 처리에서는 위의 콜백 방식을 사용할 경우 콜백 헬 발생
• 비동기 작업을 콜백에 비해 쉽게 컨트롤 가능, 비교적 가독성이 좋음.
• 오류 처리를 가시적으로 대응할 수 있음.

const fs = require('fs');

function readDirPromise() {
  return new Promise((resolve, reject) => {
    fs.readdir('.', function (err, filenames) {
      err ? reject(err) : resolve(filenames);
    });
  });
}

readDirPromise()
  .then(function (filenames) {
    console.log('filenames - ', filenames);
  })
  .catch(function (error) {
    console.log('error - ', error);
  });

Generator 방식

const fetch = require('node-fetch');

// 외부 api를 사용한다.
function getUser(generatorObject, username) {
  fetch(`https://api.github.com/users/${username}`)
    .then(res => res.json())
    .then(user => {
      // user 이름을 줄테니까 다음을 실행시켜!
      generatorObject.next(user.name)
    });
}

let main;

// 비동기 함수가 포함되어있는 메인함수
function* mainFunction() {
  let user;

  // getUser를 실행하고 멈춰있어!
  user = yield getUser(main, 'jessie');
  console.log('1user - ', user);
  user = yield getUser(main, 'kevin');
  console.log('2user - ', user);
  user = yield getUser(main, 'albert');
  console.log('3user - ', user);
}

// iterator 함수 반환
main = mainFunction();
// main 함수 실행
main.next();

async/await 방식 ( 필자가 가장 많이 쓰는 방식 )

• async, await 는 ES8(ECMAScript2017)의 공식 스펙(링크)
• promise, generator보다 더욱 절차적(동기적)인 프로그래밍 방식으로 개발가능

(async () => {
    try {
        const filenames = await fs.readdir('.');
        for (let i = 0; i < filenames.length; i++) {
            console.log(filenames[i]);
        }
    } catch (e) { console.error(e); }
})();

이벤트 루프

https://namjackson.tistory.com/30

jinn-blog.tistory.com/87