기술지원 문의는 로그인 후에 가능합니다.
확인22-09-21
안녕하세요 GitHub 한국 총판 단군소프트입니다. 오늘은 어제 1장에 이어 '개발자 워크플로 속도를 높이는 DevOps 팁_제2장'에 대한 주제로 찾아뵙게 되었습니다. 아직 제1장을 못 보신 분들이 계시다면 아래 링크를 눌러 확인해 주세요! ↓ ↓ ↓ (https://www.tangunsoft.com/tiptech/detail?id=520) 자, 그럼 이제 시작해 볼까요? 세 번째 팁: 자동 테스트와 지속적인 통합(CI)을 통해 한 단계 앞서가기 DevOps에 관한 모든 대화에서 자동화된 테스트와 지속적인 통합(CI)에 대해 듣게 될 것입니다. 그러나 자동 테스트는 일반적으로 우수한 CI 개발 관행의 일부이지만, 필수 요건은 아닙니다. (하지만 최소한 지속적인 배포 단계의 일부여야 합니다). 대부분의 팀에서는 CI 프로세스의 일부로 기본적인 유닛 테스트를 실시하고 있지만 보안 취약성, 자동 UI 테스트, 통합 테스트 등에 미달합니다.
피자를 주문하는 것부터 알람을 울리는 것까지, GitHub Actions로 할 수 있는 일은 많습니다. 이 모든 것이 워크플로우 자동화로 연결됩니다. GitHub Actions를 사용한 자동 테스트 구성은 직접 Actions 워크플로우를 작성하거나 GitHub Marketplace의 사전 빌드 Actions를 활용할 수 있습니다.
GitHub Actions 워크플로우 자동화 구축 방법 알아보기 >
GitHub Actions에 대해 자세히 알고 싶으시다면, 가이드를 확인해 주세요! - GitHub 액션을 사용하여 CI 파이프라인 생성 CI 또는 지속적인 통합은 특정 프로젝트에 대해 여러 사람의 코드를 자동으로 통합하는 프로세스입니다. CI를 잘 활용하면 작업 속도가 빨라지고, 코드가 올바르게 컴파일되고, 코드 변경이 보다 효율적으로 병합되며, 코드가 다른 모든 사용자의 작업 내용과 잘 작동할 수 있습니다.
GitHub에서 작업하고 있다면 GitHub Actions도 이 작업을 수행할 수 있습니다. GitHub Marketplace에는 사전 구축된 CI 워크플로우가 많이 있지만(또한 언제든지 직접 구축할 수 있습니다), 개발 흐름에 CI를 통합하기 시작할 때 유의해야 할 사항이 몇 가지 있습니다. 여기에는 다음이 포함됩니다.
어떤 빌드, 통합 및 테스트 자동화가 이상적으로 필요한지 생각해 보세요. 과거에 릴리스에서 문제가 발생했을 가능성이 있는 사항을 고려하여 CI에 해당 테스트를 추가할 수 있는지 확인합니다. ● 코드 테스트에 걸리는 시간과 새 코드 Push 속도를 균형 있게 조정합니다. 예를 들어, 팀이 5분마다 새로운 코드를 Push 하고 있다고 가정하였을 때, 테스트를 실행하는 데 10분이 걸리게 된다면 좋지 않습니다. 항상 체크하는 내용과 소요 시간의 균형을 유지하는 것이 가장 좋습니다. 적어도 CI 빌드에 대해서는 테스트 목록을 현실적인 수치로 줄이는 것이 좋습니다. GitHub Actions를 사용한 CI 파이프라인 작성 튜토리얼 보기> 네 번째 팁: 유연성과 속도를 높이기 위한 서버 오케스트레이션 클라우드 네이티브 어플리케이션(또는 몇 개의 서버, VM, 컨테이너 또는 호스팅 서비스만 사용하는 경우)을 구축하고 있다면 아마 몇 가지 환경을 다루고 있을 것입니다. 어플리케이션과 인프라를 적절히 연계할 수 있다는 것은 소프트웨어를 기존 인프라에서 바로 실행하려는 운영팀에 대한 의존도가 다소 낮아진다는 것을 의미합니다. 여기서 서버 오케스트레이션이 필요합니다. 서버 오케스트레이션(또는 인프라 오케스트레이션)은 주로 IT 및 DevOps 팀의 업무이며 소프트웨어 실행에 필요한 구성, 관리, 프로비저닝 및 시스템, 어플리케이션, 핵심 인프라의 조정이 포함됩니다. 프로 팁: 필요한 인프라를 정의하고 갱신할 수 있는 툴을 확인해 보세요.
마지막 팁: 반복되는 작업이라면 Bash 또는 PowerShell을 사용하여 스크립트를 작성합니다. 로컬에서 실행하는 반복 가능한 작업이 너무 많아 매주 너무 많은 시간을 할애하고 있다면 Bash 또는 PowerShell을 사용한 스크립트 작성이 더 효율적인 방법입니다. Bash는 Unix 세계에 깊은 뿌리를 두고 있습니다. IT 팀과 DevOps 팀의 주축이며, 소수의 개발자도 있습니다. 그에 비해 PowerShell은 비교적 최신입니다. Microsoft가 설계하여 2006년에 출시된 PowerShell은 Windows 환경에서 작업 자동화 및 구성 관리를 위한 명령 프롬프트와 이전 스크립트 언어를 대체했습니다.
예를 들어 Bash와 PowerShell에서 유용한 작업 중 하나는 최신 버전의 코드를 Pull > 새 Branch를 생성 > 해당 Branch로 전환 > Draft Pull Request 생성 및 GitHub로 Push 후 해당 Branch에서 VSCode를 여는 것입니다. 요점 IT 전문가, DevOps 엔지니어, 개발자 사이에는 큰 차이가 있습니다. 그러나 오늘날 소프트웨어 개발의 세계에서는 DevOps의 많은 핵심 업무들이 모든 사람의 일이 되고 있습니다. 또한 몇 가지 DevOps 기술을 습득할 수 있는 개발자는 독립적으로 작업하는 데 더 많은 시간을 할애할 수 있으며(더 효율적으로 작업할 수 있습니다) 가장 중요한 소프트웨어 구축에 계속 집중할 수 있습니다.
유익하셨나요? 다음 콘텐츠도 유익한 정보 가득 담아 돌아오겠습니다:) 긴 글 읽어 주셔서 감사합니다. |