24.08.08 Dev, C#

24.08.08 Dev, C#

Dev

CI/CD 파이프라인

CI(Continuous Integration)

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

CD(Continuous Delivery / Deployment)

• CI/CD의 CD는 지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.
• 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
• 지속적인 제공(Continuous Delivery)
  • 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있다.
  • 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해준다.
  • 지속적인 제공은 귀찮은 push 작업없이 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.
• 지속적인 배포(Continuous Deployment)
  • 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다.
  • 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.
  • 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용한다.

장점

• 변경 사항을 자주 푸시하고자 하는 개발자와 안정적인 애플리케이션을 원하는 운영 담당자 사이의 마찰을 해결한다.
• 코드 변경을 사용자에게 푸시하기 전에 검증하기 위해 개발 팀은 지속적인 테스트를 실행해야 한다.
• 큰 변경보다 안정적으로 통합 및 테스트가 가능한 더 작은 규모의 증분적 코드 변경을 수행하도록 개발자를 독려한다.
• 개로운 기능을 위한 더 넓은 범위의 개발 작업을 수행하는 동시에 신속한 수정 요청까지 받는 팀에 작업의 유연성을 부여한다.
• 기능, 성능 및 데이터 중심 테스트를 더 많이 실행해서 더 높은 품질의 애플리케이션을 제공하고 프로덕션 결함을 줄일 수 있게 해준다.

CI/CD Pipeline

 

파이프 라인

• 컴퓨터 과학에서 데이터 파이프 라인은 제공된 데이터 또는 코드에 대해 사전 정의 된 작업을 수행하는 일련의 처리 단계이다.
• 파이프 라인 사용의 목적은 반복적인 프로세스를 자동화하여 시간을 절약하고 정밀도를 높이는 것이다.
• 파이프 라인의 이러한 장점은 CI/CD 인프라와의 호환성과 효율성을 높여준다. 특히 CI/CD 파이프 라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계를 수행할 수 있다.

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

• 빌드(소프트웨어 컴파일)
• 테스트(호환성 및 오류 검사)
• 릴리스(버전 제어 저장소의 애플리케이션 업데이트)
• 배포(개발에서 프로덕션 환경으로의 변환)
• 규정 준수 및 유효성 검사
• CI/CD 파이프 라인 목표는 빌드, 테스트 및 제공을 수동 처리보다 더 빠르고 자동화되고 안정적으로 만드는 것이다.

---

참조

https://inpa.tistory.com/entry/👩‍💻-CI-CD-파이프-라인-이란

빌드 이벤트 지정

과정

1. 솔루션 탐색기에서 빌드 이벤트를 지정할 프로젝트를 선택한다.
2. 프로젝트 메뉴에서 (ProjectName) 속성을 클릭하거나, 솔루션 탐색기에서 Alt+Enter를 누른다.
3. 빌드 > 이벤트를 선택한다.
4. 빌드 전 이벤트 섹션에서 빌드 이벤트의 구문을 지정한다.
   • 프로젝트가 최신 상태이고 빌드가 트리거되지 않으면 빌드 전 이벤트가 실행되지 않는다.
5. 빌드 후 이벤트 섹션에서 빌드 이벤트의 구문을 지정한다.
   • .bat 파일을 실행하는 모든 빌드 후 이벤트 명령 앞에 call 문을 추가한다. 예를 들어 call MyFile.bat 또는 call MyFile.bat call MyFile2.bat 이다. 경로는 프로젝트 폴더의 상대 경로이거나 절대 경로일 수 있다.
6. 빌드 후 이벤트 실행 상자에서 빌드 후 이벤트를 실행할 조건을 지정한다.
   • 긴 구문을 추가하거나 빌드 전 이벤트/빌드 후 이벤트 명령줄 대화 상자에서 임의의 빌드 매크로를 선택하려면, 줄임표 단추(…)를 클릭하여 편집 상자를 표시한다.

빌드 이벤트 명령 만들기

• 빌드 이벤트 명령에는 명령 프롬프트 또는 .bat 파일에서 유효한 모든 명령이 포함될 수 있다. 일괄 처리 파일의 이름 앞에 call 을 사용하여 모든 후속 명령이 실행되도록 한다. 일괄 처리 파일 자체는 출력 폴더에서 실행된다.
• 모든 구성에 동일한 일괄 처리 파일이 필요한 경우 프로젝트 파일과 동일한 폴도에 배치하고 해당 파일에 대한 상대 경로를 사용할 수 있다. 예를 들면 call ../../prebuild.bat 다음과 같다.
• Powershell MyPowerShellScript.ps1 와 같은 명령을 입력하여 PowerShell 스크립트를 실행할 수 있다. PowerShell 스크립트의 경로는 절대 경로이거나 프로젝트 디렉터리를 기준으로 할 수 있다. 스크립트를 실행하려면 운영 체제의 PowerShell 스크립트에 대한 실행 정책이 적절하게 설정되어 있는지 확인해야 한다.
• bash와 같은 다른 셸을 사용하려는 경우 일반적으로 Windows 명령 프롬프트에서 셸 스크립트를 시작하는 데 사용하는 것과 동일한 명령 구문을 사용한다.

프로젝트 파일에서

• 이전 단계를 수행할 때 Visual Studio는 제공된 단계를 실행하는 데 필요한 MSBuild 코드 PreBuild 또는 PostBuild 대상을 추가하여 프로젝트 파일을 수정한다. 프로젝트 파일을 열고 단계를 볼 수 있다. 변경 내용을 저장한 후 프로젝트 속성의 빌드 > 이벤트 섹션에 변경 내용이 표시된다.
• Exec 요소는 MSBuild Exec 작업을 참조한다.

오류 및 기타 출력

• 빌드 이벤트의 출력은 출력 창의 빌드 섹션에 기록된다. 다른 창보기 > 출력 창을 선택하거나 Ctrl+Alt+O를 누리면 볼 수 있다.
• 빌드 전 또는 빌드 후 이벤트가 성공적으로 완료되지 않으면 성공적인 작업을 나타내는 0 이외의 코드로 이벤트 작업이 종료되도록 하여 빌드를 종료할 수 있다. 0 종료 코드는 성공적인 작업을 나타낸다. 다른 종료 코드는 오류로 간주된다.
• 빌드 전 이벤트가 실패하면 오류 목록 창에 다음과 같은 오류가 표시될 수 있다.

MSB3073    The command "call c:\\source\\repos\\prebuild.bat" exited with code 1.

• 오류 목록 창에 정보가 충분하지 않은 경우 출력 창을 사용하여 일괄 처리 파일의 출력을 포함하여 전체 빌드 출력을 볼 수 있다.
  • 오류 목록 창은 이벤트에 대해 입력한 첫 번째 줄인 한 줄의 출력으로 제한된다. 오류 목록 창 출력이 중요한 경우 이벤트에 둘 이상의 줄을 배치하면 안된다. Windows 명령 프롬프트 또는 운영 체제에서 일괄 처리 파일을 만든 다음 이벤트에만 사용한다.

매크로

• 일반적으로 사용할 수 있는 매크로는 MSBuild 공용 속성에 나열된다. .NET SDK 프로젝트의 경우 추가 속성은 Microsoft.NET.Sdk의 MSBuild 속성에 나열된다.
• 빌드 이벤트에 대한 스크립트에서 프로젝트 이름 또는 출력 폴더 위치와 같은 일부 프로젝트 수준 변수의 값을 참조하려고 할 수 있다. 이전 버전의 Visual Studio에서는 이를 매크로라고 했다. 최신 버전의 Visual Studio에서 매크로에 해당하는 속성은 MSBuild 속성이다.
• MSBuild는 빌드를 수행할 때 Visual Studio에서 프로젝트 파일을 처리하는 데 사용하는 빌드 엔진이다. IDE의 빌드 이벤트는 프로젝트 파일에서 MSBuild 대상을 생성한다.
• 프로젝트 파일의 대상에서 사용 가능한 모든 MSBuild 속성(예: $(OutDir) 또는 $(Configuration) 을 사용할 수 있다. 이 이벤트에서 사용할 수 있는 MSBuild 속성은 프로젝트 파일에서 암시적으로 또는 명시적으로 가져온 파일(예: .props 및 .targets 파일) 및 프로젝트 파일(예: PropertyGroup 요소)에 설정된 속성에 따라 달라진다.
• 각 속성의 정확한 철자를 사용해야 한다. 속성의 철자가 잘못되면 오류가 보고되지 않는다. 대신, 정의되지 않은 속성은 빈 문자열로 평가된다.

주의 사항

• 이미 빌드가 진행한 후에 다시 빌드를 진행 할 때는, 빌드가 생략되므로 매크로의 실행도 생략될 수 있다. 따라서 빌드와 매크로가 제대로 실행되었는지 VisualStudio의 Output Window를 확인해야한다.
• 매크로 실행 중에 오류가 발생하거나, 잘못된 매크로를 작성했을 때 오류를 확실하게 알 수 없는 경우도 있다. 따라서 복잡한 매크로는 배치파일(.bat)로 작성하거나 실행파일(.exe)로 작성하는 것이 도움이 될 수 있다.

---

참조

https://learn.microsoft.com/ko-kr/visualstudio/ide/how-to-specify-build-events-csharp?view=vs-2022

C#

Oneof

• Google Protocol Buffer(프로토콜 버퍼)에서 제공하는 기능으로, 단일 메시지 필드에 여러 개의 필드 중 하나를 저장할 수 있게 해준다.
• 효율적인 데이터 전송을 위해 사용되며, 서로 배타적인 여러 필드 중 하나만 설정될 수 있다는 점에서 구조적으로 유용하다.

주요 특징

1. 배타적 필드
   • oneof 내에서 정의된 필드는 동시에 하나만 설정될 수 있다. 이는 oneof에 속한 필드들 중 하나를 설정하면 다른 필드들은 자동으로 초기화된다.
2. 절약된 메모리 사용
   • oneof는 하나의 메모리 공간을 여러 필드가 공유하도록 하여 메모리 사용을 절약할 수 있다. 설정된 필드가 어떤 것이든 해당 데이터만을 저장하므로, 다른 필드의 값은 메모리에서 제거된다.
3. 명시적 필드 선택
   • oneof는 현재 설정된 필드를 명확히 하여 데이터의 구조적 명확성을 높인다. 프로토콜 버퍼 메시지를 다룰 때 현재 어떤 필드가 설정되어 있는지를 쉽게 확인할 수 있다.

주의 사항

• 초기화되지 않은 상태
  • oneof 필드가 설정되지 않은 경우, oneof의 상태를 나타내는 기본 필드는 unset 상태로 존재한다. C#에서는 주로 해당 oneof 필드를 식별하는 열거형 값으로 설정된 필드를 확인한다.
• 데이터 무결성
  • oneof를 사용하여 메시지 구조를 명확히 하고, 동시에 존재할 수 없는 필드들의 데이터를 방지하여 데이터 무결성을 유지할 수 있다.