DevOps 이것저것

 

데브옵스 엔지니어는 소프트웨어 개발과 운영의 경계를 연결하고, 통합하여 소프트웨어 제공 프로세스를 관리하는 역할을 합니다. 이를 통해 소프트웨어 제공의 효율성을 높이고, 안정적인 서비스 제공을 목표로 합니다.

 

데브옵스 엔지니어는 주로 다음과 같은 일을 수행합니다.

1. 개발과 운영의 통합: 개발자와 운영자 사이의 소통과 협업을 원활하게 하여 소프트웨어 개발과 배포를 빠르고 안정적으로 수행할 수 있도록 합니다.
2. 자동화: CI/CD(Continuous Integration/Continuous Deployment) 파이프라인을 구성하여 빌드, 테스트, 배포 등의 과정을 자동화하고, 인프라 자동화와 코드 배포 자동화를 통해 소프트웨어 제공 프로세스의 효율성을 높입니다.
3. 모니터링 및 로깅: 운영 중인 시스템의 상태를 모니터링하고 로깅하여, 장애 발생 시 빠른 대응을 할 수 있도록 합니다.
4. 보안: 시스템 보안을 강화하고, 개발 및 운영에서 발생할 수 있는 보안 이슈에 대한 대비책을 마련합니다.
5. 클라우드: 클라우드 서비스를 활용하여 인프라를 관리하고, 클라우드 기반의 인프라와 애플리케이션을 관리합니다.

 

 

1. 깃 허브 충돌(conflict) 발생 기준

 

Git에서는 파일을 텍스트 파일로 취급하며, 병합 작업을 수행할 때 텍스트 파일 내에서 변경된 부분의 위치를 비교합니다. 만약 다른 브랜치에서 수정한 코드와 병합하려는 브랜치에서 수정한 코드가 같은 라인에 위치한다면, 이 부분에서 충돌이 발생할 수 있습니다. 따라서 같은 파일의 다른 코드 라인을 수정한다면 충돌이 발생하지 않는다!

 

 

 

 

 

---

2. 깃 컨벤션

 

브랜치 전략

작업 순서

• 평소
  1. develop에서 feature/~ 브랜치 생성 후 작업
  2. 로컬 테스트 후 이상 없을 시 develop으로 PR
  3. 상호 코드 리뷰
  4. Approve시 develop에 merge
  5. 어느 정도 커밋이 쌓이면 develop에서 release/<version> 브랜치 생성
  6. QA 진행, 수정사항 발생 시 해당 release 브랜치에서 작업 후 commit
  7. 모든 테스트 완료 후 main으로 merge 및 배포
• 긴급 수정(hotfix)
  1. 관리자에게 연락
  2. main에서 hotfix브랜치 생성 후 작업
  3. 로컬 테스트 후 main 으로 PR
  4. 관리자 확인 후 merge

Git 사용하기

• Branch Usage
  • Repository name should be like following format
    • feature/<issue_number>
    • feature/<feature_name>
    • release/<version_number>
    • hotfix/<issue_number>
• Commit Message
  • Commit with the smallest change unit
  • Use category in commit messages
    • int: only for initial commit
    • doc: changes document or comment
    • ftr: add new feature
    • mod: modify existing feature
    • fix: fix an error or issue
    • rfc: refactor code
    • add: add new file or directory
    • rmv: remove existing file or directory
  • Example
    • int: initial commit

 

 

---