개발자 워크플로 속도를 높이는 DevOps 팁_제2장

안녕하세요 GitHub 한국 총판 단군소프트입니다.
오늘은 어제 1장에 이어 '​​개발자 워크플로 속도를 높이는 DevOps 팁_제2장'에 대한 주제로 찾아뵙게 되었습니다.

아직 제1장을 못 보신 분들이 계시다면 아래 링크를 눌러 확인해 주세요!

↓ ↓ ↓

개발자 워크플로우 속도를 높이는 DevOps 팁_제1장

 

자, 그럼 이제 시작해 볼까요?

---

 

세 번째 팁: 자동 테스트와 지속적인 통합(CI)을 통해 한 단계 앞서가기

DevOps에 관한 모든 대화에서 자동화된 테스트와 지속적인 통합(CI)에 대해 듣게 될 것입니다. 그러나 자동 테스트는 일반적으로 우수한 CI 개발 관행의 일부이지만, 필수 요건은 아닙니다. (하지만 최소한 지속적인 배포 단계의 일부여야 합니다).

대부분의 팀에서는 CI 프로세스의 일부로 기본적인 유닛 테스트를 실시하고 있지만 보안 취약성, 자동 UI 테스트, 통합 테스트 등에 미달합니다.

그래도 (1) 코드가 Main Branch와 함께 작동하는지 확인하는 것과 (2) 미리 보안 취약성 및 기타 문제와 같은 사항을 파악하여 DevOps 팀의 워크로드를 줄일 수 있는 두 가지 방법으로 워크플로우를 강화할 수 있습니다.

방법은 다음과 같습니다.

​

- GitHub 액션을 사용하여 자동 테스트 실행​

피자를 주문하는 것부터 알람을 울리는 것까지, GitHub Actions로 할 수 있는 일은 많습니다. 이 모든 것이 워크플로우 자동화로 연결됩니다. GitHub Actions를 사용한 자동 테스트 구성은 직접 Actions 워크플로우를 작성하거나 GitHub Marketplace의 사전 빌드 Actions를 활용할 수 있습니다.

​

프로 팁: Pull Request에 따라 실행되는 작업 워크플로우를 사용하면 Main Branch에 병합하기 전에 보안 취약성, 코드 문제 등을 확인할 수 있습니다. 이를 통해 한 걸음 앞서서 Main Branch을 깔끔하게 유지할 수 있습니다.

GitHub Actions 워크플로우 자동화 구축 방법 알아보기 >

​

일회용 테스트 환경에 배포하도록 워크플로우를 구성할 수도 있습니다. 즉, 테스트를 실행하고 응용 프로그램을 테스트할 수 있는 환경에도 변경 사항을 배포할 수 있습니다. 작업 완료 후 이러한 테스트 환경을 자동으로 삭제하도록 워크플로우를 구성할 수도 있습니다.

이 모든 것은 실제 운영환경에 들어가기 전에 최대한 많은 테스트해야 한다는 것을 의미합니다.

GitHub Actions에 대해 자세히 알고 싶으시다면, 가이드를 확인해 주세요!

​

- GitHub 액션을 사용하여 CI 파이프라인 생성​

CI 또는 지속적인 통합은 특정 프로젝트에 대해 여러 사람의 코드를 자동으로 통합하는 프로세스입니다.

CI를 잘 활용하면 작업 속도가 빨라지고, 코드가 올바르게 컴파일되고, 코드 변경이 보다 효율적으로 병합되며, 코드가 다른 모든 사용자의 작업 내용과 잘 작동할 수 있습니다.

​

가장 강력한 CI 워크플로우는 코드를 서버에 Push 할 때마다 사용자가 신경 쓰는 모든 사항을 테스트하는 워크플로우입니다.

​

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은 모두 크로스 플랫폼입니다(Windows 배경을 가진 대부분의 사용자는 PowerShell을 사용하고 Linux 또는 MacOS에 익숙한 대부분의 사용자는 Bash를 사용합니다).

​

프로 팁: Bash와 PowerShell의 동작 방식은 다릅니다. PowerShell이 개체를 이용하여 작동하는데 반해 Bash는 정보를 문자열로 전달합니다.

예를 들어 Bash와 PowerShell에서 유용한 작업 중 하나는 최신 버전의 코드를 Pull > 새 Branch를 생성 > 해당 Branch로 전환 > Draft Pull Request 생성 및 GitHub로 Push 후 해당 Branch에서 VSCode를 여는 것입니다.

​

요점

IT 전문가, DevOps 엔지니어, 개발자 사이에는 큰 차이가 있습니다. 그러나 오늘날 소프트웨어 개발의 세계에서는 DevOps의 많은 핵심 업무들이 모든 사람의 일이 되고 있습니다. 또한 몇 가지 DevOps 기술을 습득할 수 있는 개발자는 독립적으로 작업하는 데 더 많은 시간을 할애할 수 있으며(더 효율적으로 작업할 수 있습니다) 가장 중요한 소프트웨어 구축에 계속 집중할 수 있습니다.

---

지금까지 '개발자 워크플로 속도를 높이는 DevOps 팁'을 다뤄봤습니다.

​

유익하셨나요?

다음 콘텐츠도 유익한 정보 가득 담아 돌아오겠습니다:)

​

긴 글 읽어 주셔서 감사합니다.

 

 

이 글은 https://github.blog/2021-11-30-5-devops-tips-to-speed-up-your-developer-workflow/을 번역한 글입니다.