Kimsora✨
article thumbnail
Published 2022. 12. 7. 17:02
[Deploy] CI/CD 웹
320x100
반응형

개발 프로세스

소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle)을 기반으로 만들어졌다

 

 

(1) 요구사항 분석

  • 기능과 제약 조건, 목표 등을 정의

(2) 설계

  • 수행 방법을 논리적으로 결정

(3) 구현

  • 프로그래밍 언어를 사용하여 실제 프로그램을 작성
  • 프로그래밍 언어, 기법, 스타일, 순서 결정

(4) 테스트

  • 검사 및 평가

(5)배포 및  유지보수

  • 시스템이 인수되고 설치된 후 일어나는 모든 활동(비용이 가장 많이 소요된다.

       -수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행.

       -적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업

       -완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업.

       -예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업

 

 

 

  애자일(모던 개발 프로세스) 워터폴(전통개발 프로세스)
장점 개발 과정이 빠르면서도 유연하다. 개발 주기가 애자일보다 형식적, 연속적이긴 하지만 프로세스가 길고 순서가 잡혀 있기 때문에 팀의 규모에 상관없이 따르기가 쉽다.
짧고 반복적인 스프린트로 구성돼 있으면서 품질에 초점을 맞추기 때문에, 워터폴 방법론보다 빠르게 결함을 식별 및 수정할 수 있다. 개발 주기가 이미 정해져 있어서 팀이 새로운 프로젝트를 안정적으로 시작할 수 있다.
여러 소규모 팀들이 개발 과정상의 여러 과제를 각각 할당 받아 처리할 수 있다 프로젝트 요구사항이 확정돼 있기 때문에, 프로젝트를 실행하기가 수월하며 개발 목표를 자주 변경하지 않아도 된다.
짧은 반복 과정을 거치므로 필요 시 개발과정 중에 신속하게 제품 변경을 할 수 있다. 프로젝트 전 과정에 필요한 예산과 자원이 초기에 확정되기 때문에 예상 결과와 리스크를 통제하기가 훨씬 쉽다.
단점 스프린트에 대한 경험이 있으면서 빠른 반복 작업에 익숙한 스크럼 마스터가 필요하다. 개발이 순차적으로 진행되기 때문에 앞단계가 완성돼야 다음 단계로 넘어갈 수 있다. 이로 인해 개발 속도가 느리며 유연성이 떨어진다.
고객이 수많은 변경사항을 검토해야 하는 번거로움이 발생할 수 있다. 테스팅 단계에 이르러서야 이슈가 발견되곤 한다.
팀원이 다양한 시간대의 지역에 흩어져 있음에도 잘 조직되지 않거나 자립성이 없는 경우, 애자일 방법론을 채택하면 문제가 발생할 수 있다. 개발 요구사항이 프로젝트 초기에 정해지기 때문에 범위 변경이 자유롭지 못하다.
이런 조직에
적합함
 		 고성능 소프트웨어 개발 팀 중에서도 특히 소프트웨어 개발 분야 팀 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 팀
고품질의 결과물과 지속적인 개선에 초점을 맞춘 조직. 특히 이들이 생각하는 가치 제안이나 경쟁 차별화요소에 퀄리티가 포함되는 경우. 프로젝트 팀의 경험이 적은 경우
IBM, 시스코, AT&T, 마이크로소프트처럼 크고 복잡한 회사들이 프로세스를 간소화함으로써 변화에 더욱 신속하게 대응하고자 할 때 개발상의 변경이나 리스크에 덜 민감한 기업
고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업
프로젝트가 완벽하게 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 팀. 요구사항이 간단한 프로젝트
  타임라인이 긴 프로젝트



SaaS(서비스형 소프트웨어)

인터넷 브라우저를 통해 최종 사용자에게 애플리케이션을 제공하는 클라우드 기반 소프트웨어 모델이다

SaaS 공급업체는 고객이 필요에 따라 액세스할 수 있는 서비스 및 애플리케이션을 호스팅한다

=>하드웨어, 소프트웨어 도구 및 애플리케이션을 자체 데이터 센터 또는 클라우드 환경에서 관리하며 사용자는 브라우저 또는 모바일 애플리케이션에서 직접 소프트웨어에 액세스할 수 있다. SaaS는 구독 기반 모델을 제공하기 때문에 소프트웨어 사용을 비즈니스 요구 사항에 따라 늘리거나 줄일수 있다

DevOps

애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크이다

DevOps 사례는 애플리케이션 개발 팀(Dev)과 해당 IT 운영 팀(Ops) 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려한다

"Dev"와 "Ops" 간의 이러한 긴밀한 관계는 초기 소프트웨어 계획부터 코딩, 구축, 테스트 및 릴리즈 단계와 구축, 운영 및 지속적인 모니터링에 이르는 DevOps 라이프사이클의 모든 단계에 걸쳐 계속되고 이러한 관계는 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 된다 이러한 노력이 제공하는 결과 중 하나는 필요한 기능 변경 또는 추가 기능을 더 빠르고 지속적으로 릴리즈할 수 있다는 것이다

CI/CD

지속적 통합(Continuous Integration, CI)

  • Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계
  • Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
  • Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

CI는 간단히 요약하자면 빌드/테스트 자동화 과정 과정이다  성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다

지속적 통합의 실행은 소스/버전 관리 시스템에 대한 변경 사항을 정기적으로 커밋하여 모든 사람에게 동일 작업 기반을 제공하는 것으로 시작한다 커밋할 때마다 빌드와 일련의 자동 테스트가 이루어져 동작을 확인하고 변경으로 인해 문제가 생기는 부분이 없도록 보장한다. 지속적 통합은 그 자체로 유익하지만 CI/CD 파이프라인을 구현하기 위한 첫 번째 단계이기도 하다

 

지속적 배포(Continuous Delivery/Deployment, CD)

  • Release : 배포 가능한 소프트웨어 패키지를 작성
  • Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출합니다. 실질적인 배포 
  • Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지

CD는 간단히 말하면 배포 자동화 과정이다 지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용 된다 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 사용된다

지속적 배포는 빌드, 테스트 및 배포 단계를 자동화하는 DevOps 방식을 논리적 극한까지 끌어 올린다 코드 변경이 파이프라인의 이전 단계를 모두 성공적으로 통과하면 수동 개입 없이 해당 변경 사항이 프로덕션에 자동으로 배포된다. 지속적 배포를 채택하면 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다  또한 성숙하고 입증된 지속적 통합 및 지속적인 전달 단계를 기반으로 하고 간단한 코드 변경이 정기적으로 마스터에 커밋되고, 자동화된 빌드 및 테스트 프로세스를 거치며 다양한 사전 프로덕션 환경으로 승격되며, 문제가 발견되지 않으면 최종적으로 배포된다. 강력하고 신뢰할 수 있는 자동화 배포 파이프라인을 구축하면 하루에도 여러 번 이루어지는 릴리스가 특별하지 않은 일상이 된다

 

CI/CD 파이프라인

수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인이라고 한다.

파이프 라인 사용의 목적=> 반복적 인 프로세스를 자동화하여 시간을 절약하고 정밀도를 높이는 것

 

  1. Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행
  2. Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행
  3. Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

CI / CD 파이프 라인을 구성하는 요소

  • 빌드 (소프트웨어 컴파일),
  • 테스트 (호환성 및 오류 검사)
  • 릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
  • 배포 (개발에서 프로덕션 환경으로의 변환)
  • 규정 준수 및 유효성 검사

 

 

Github Action

Github에서 제공하는 워크플로우(workflow)를 자동화하도록 도와주는 도구이다. 테스트, 빌드, 배포 등의 다양한 작업들을 자동화하여 처리한다.

  • Source: Github reference 브랜치에 코드가 커밋
  • Build: github acitons의 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드
  • Deploy: github acitons의 YAML 파일에 적힌 명령어를 토대로 s3로 빌드 결과를 업로드

  • 1) Workflow
    • 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
    • 최상위 개념
    • Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨
  • 2) Event
    • Workflow를 Trigger(실행)하는 특정 활동이나 규칙
    • 예를 들어 다음과 같은 상황을 사용할 수 있음
      • 특정 브랜치로 Push하거나
      • 특정 브랜치로 Pull Request하거나
      • 특정 시간대에 반복(Cron)
      • Webhook을 사용해 외부 이벤트를 통해 실행
  • 3) Job
    • Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행됨
    • 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능함
  • 4) Step
    • Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있음
  • 5) Action
    • Workflow의 가장 작은 블럭(smallest portable building block)
    • Job을 만들기 위해 Step들을 연결할 수 있음
    • 재사용이 가능한 컴포넌트
    • 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있음
  • 6) Runner
    • Gitbub Action Runner 어플리케이션이 설치된 머신으로, Workflow가 실행될 인스턴스
    • Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉨
    • Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB

 

 

 

name: sub-branch

on:
  push:
    branches:
      - sub-branch    # sub-branch[branch name] 브랜치에서 push 이벤트가 일어났을 때 실행

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - name: Checkout source code
        uses: actions/checkout@master

      - name: Cache node modules  # node modules 캐싱
        uses: actions/cache@v1
        with:
          path: node_modules
          key: ${{ runner.OS }}-master-build-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.OS }}-build-
            ${{ runner.OS }}-

      - name: Install Dependencies # node module install
        run: yarn

      - name: Build # project build
        run: yarn build

      - name: Deploy 
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: |
          aws s3 sync ./build s3://[bucket name]

 

 

 

https://fe-19-kimsorara-s3.s3.ap-northeast-2.amazonaws.com/index.html

 

728x90
반응형

'웹' 카테고리의 다른 글

WebSocket 과 WebRTC  (1) 2023.09.24
CORS 정책이 필요한 이유 와 Proxy  (0) 2022.12.08
[최적화] Optimization  (0) 2022.12.05
[사용자 친화 웹] 웹 표준 & 접근성  (0) 2022.11.05
UI, UX  (0) 2022.10.24
profile

Kimsora✨

@sorarar

포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!

검색 태그

WH

티스토리툴바