DI (Dependency Injection) : 의존성 주입 

  • 객체 지향 프로그래밍에서 중요한 디자인 패턴 중 하나
  • 객체가 필요로 하는 의존 객체를 외부에서 주입하하여 객체 간의 결합도를 낮추는 방식

 

사용하는 이유

의존성 주입을 통해 객체는 자신이 사용할 의존 객체를 직접 생성하지 않고, 외부에서 생성된 객체를 주입받기 때문입니다.

이로 인해 객체는 자신의 구현에만 집중할 수 있으며, 변경에 유연하게 대응할 수 있습니다.

 

장점

코드의 재사용성 증가, 코드의 유지보수성 향상, 객체 간의 결합도 감소, 단위 테스트 용이성 증가

 

 

 

Nest.js 에서 DI 하는 방법

  • DI는 의존성을 “런타임”시점에 주입시켜주는 기술
  • TypeScript는 컴파일 시점에만 인터페이스가 존재하고 “런타임” 시점에는 인터페이스가 사라지게 된다

→ DI컨테이너가 런타임 시점에 의존성을 주입시켜주지 못 해서 에러발생

 

프로바이더를 모듈에 등록할때 사용자 지정 프로바이더 문자열 토큰 주입 방식으로 해결

 

export interface TestRepository {
   outputText(text: string): void;
}
@Injectable()
export class TestConsoleLog implements TestRpository {
  outputText(text: string): void {
    console.log(text);
  }
}
@Module({
  imports: [TypeOrmModule.forFeature([Test])],
  controllers: [WorkoutLogController],
  providers: [TestService, 
         // provide에 문자열 토큰 지정
         { provide: 'test', useClass: TestConsoleLog }
         ],
})

    

@Injectable()
export class TestService {
  constructor(
    @Inject('test') //// Inject 데코레이터 사용해서 porivde에 등록한 문자열 토큰 사용
    readonly testRepository: TestRepository,
  ) {}
  
  outputMessage(message: string): void{
    this.testRepository.printText(message);
  }
  
}

 

문자열 토큰방식으로 프로바이더를 등록 후 의존하고 있는 인터페이스에 @Inject('등록한 문자열 토큰') 데코레이터를 달아주면 useClass에 명시한 구현체가 주입된다.

 

 

참고 자료

f-lab -스프링 프레임워크와 의존성 주입(DI) 이해하기

median - NestJS 인터페이스로 DI하기

오류 내용

[remote rejected] main -> main (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/deploy.yml` without `workflow` scope)

 

Access Token 이  workflow 를 수정하거나 업데이트할 권한이 없다.

 

해결방법

깃허브 홈페이지에서 

Settings > Developer Settings > Token  으로 이동

 

발급된 토근에서  workflow 클릭 하여 허용된 목록을 수정한다.

CI/CD 를 구축할 수 있는 툴

  • Github Actions
  • Jenkins
  • Circle CI
  • Travis CI

→ Github Actinos 선택 이유

1. Github 과 하나로 통일된 환경에서 CI 수행 가능

2. 빌드용 서버가 따로 필요없다. → 비용절감, 시간 단축

3. 공개 레포지토리는 무료로 사용가능

Github Actions 개념 정리

GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다. 리포지토리에 대한 모든 끌어오기 요청을 빌드 및 테스트하거나 병합된 끌어오기 요청을 프로덕션에 배포하는 워크플로를 만들 수 있습니다.

GitHub Actions은(는) 단순한 DevOps 수준을 넘어 리포지토리에서 다른 이벤트가 발생할 때 워크플로를 실행할 수 있도록 합니다. 예를 들어 누군가가 리포지토리에서 새 이슈를 만들 때마다 워크플로를 실행하여 적절한 레이블을 자동으로 추가할 수 있습니다.

docs.github.com

 

요약

  • 리포지토리의 이벤트에 따라 정의된 로직을 자동으로 실행하는 자동화 도구
  • 로직을 실행시킬 수 있는 일종의 컴퓨터

CI/CD 의 기본적인 흐름

 

강의에서 퍼온 그림

 

  1. 작성한 코드를 Commit 하여 GitHub 에 Push
  2. Push를 감지하여 GitHub Actions에 작성한 로직이 실행
    • 로직 예) 프로젝트를 빌드 -  빌드된 프로젝트를 테스트 - 모든 테스트를 통과하면 서버로 배포
  3. 서버에서 배포된 최신 코드로 서버를 재실행

 

 

참고 강의

[인프런 강의] 비전공자도 이해할 수 있는 CI/CD 입문 실전

Continuous Integration, Continuous Deployment

Test, Merge, Deploy 의 과정을 자동화 하는 걸 의미

 

필요성?

새로운 기능을 추가 후, commit -> merge  과정을 거친다.
그 후 배포를 할때  서버 컴퓨터에 접속을 해서 새로운 코드를 받아서 실행 시켜주어야 한다. 

매번 이 과정을 거치는 것이 귀찮은 일...

-> 이런 과정을 자동화시키기 위해 CI/CD가 필요하다.

 

CI/CD 과정

Test 를 작성하지 않은 서비스에서는 test 과정을 빼도 된다.

패킷(Packet) 과 프레임(Frame)은 네트워크에서 사용되는 데이터 단위이지만, 사용되는 OSI 계층이 다르고 차이가 있습니다.

 

패킷(Packet) 과 프레임(Frame) 비교

  패킷 프레임
위치 OSI 3 계층 네트워크 계층 OSI 2계층 데이터링크 계층
역할 데이터를 네트워크를 통해 전달하기 위한 단위 데이터를 동일 네트워크 내에 다른 장치로 전달하기 위한 단위
주소 체계 IP 주소 사용 MAC 주소 사용
구성요소 - 헤더(Header)
    IP 주소(출발지와 목적지), 패킷의 크기,
    프로토콜 정보 등

- 데이터(Data)
   전송될 실제 데이터(페이로드)
- 헤더(Header)
   출발지와 목적지의 MAC 주소, 프레임 유형,
    제어 정보 등이 포함됩니다.

- 데이터(Data) 
   상위 계층에서 전달된 데이터(예: 패킷).

- 트레일러(Trailer)
   데이터의 무결성을 확인하기 위한 오류 검출 정보
    (FCS, Frame Check Sequence) 등이 포함

  
설명 전송 계층(OSI 4계층)에서 전달된 세그먼트(segment)에 네트워크 계층의 헤더(IP 헤더)를 추가하여 만들어집니다.  네트워크 계층(OSI 3계층)에서 전달된 패킷에 데이터 링크 계층의 헤더와 트레일러를 추가하여 만들어집니다.
     

 

+ Recent posts