DevOps 도구

탐색 단계에서 DevOps 팀은 프로젝트의 범위를 조사하고 정의합니다. 특히 사용자 조사, 목표 설정, 성공 정의와 같은 활동이 포함됩니다.

Mural 및 Miro와 같은 도구는 전체 소프트웨어 팀이 아이디어를 수집하고 조사를 수행할 수 있도록 합니다. Jira Product Discovery는 이 정보를 실행 가능한 입력으로 체계화하고 개발 팀을 위해 작업의 우선 순위를 정합니다. 우선 순위를 정할 때 사용자 피드백의 백로그도 염두에 두어야 합니다.

Product Discovery는 제품 디자인의 가장 첫 번째 활동으로, 의사 결정의 기준이 됩니다. Product Discovery 단계에서 사용자 문제에 관한 매우 중요한 정보를 모두 수집한 다음 해결 방법을 제공할 수 있습니다.

"비동기 브레인스토밍"을 장려하는 도구를 찾는 것이 좋습니다. 모두가 아이디어, 전략, 목표, 요구 사항, 로드맵 및 설명서와 같은 모든 것을 공유하고 의견을 제시하는 것이 중요합니다.

애자일 핸드북을 따라서 개발 및 운영 팀이 작업을 더 작고 관리하기 쉬운 부분으로 나누어 더 빠르게 배포할 수 있는 도구를 권장합니다. 이를 통해 사용자를 빠르게 이해하고 피드백을 기반으로 제품을 최적화하는 데 도움이 됩니다. 스프린트 계획, 이슈 추적을 제공하고 공동 작업을 허용하는 도구(예: Jira)를 찾아보세요.

또 다른 좋은 방법은 사용자 피드백을 지속적으로 수집하고, 실행 가능한 입력으로 구성하고, 개발 팀을 위해 이러한 작업의 우선 순위를 정하는 것입니다. “비동기식 브레인스토밍”을 장려하는 도구를 찾아보세요(필요한 경우). 모든 사람이 아이디어, 전략, 목표, 요구 사항, 로드맵 및 문서와 같은 모든 것을 공유하고 의견을 제시하는 것이 중요합니다.

통합 및 기능 플래그를 잊지 마세요. 기능이나 프로젝트의 범위를 결정할 때마다 개발 백로그에서 사용자 스토리로 변환해야 합니다. 기능 플래그는 팀이 기능을 활성화 및 비활성화할 수 있도록 하는 코드 베이스의 조건문입니다.

이 단계에 대한 자세한 내용은 Atlassian 제품 관리자의 백로그 정리 및 우선 순위 지정에 대한 이 게시물을 확인하세요.

프로덕션과 동일한 개발 환경

Puppet과 Chef는 주로 운영에 도움이 되지만 개발자는 Kubernetes 및 Docker와 같은 오픈 소스 도구를 사용하여 개별 개발 환경을 프로비저닝합니다. 프로덕션에 대한 일회용 가상 복제 환경에서의 코딩은 더 많은 작업을 완료하는 데 도움이 됩니다.

모든 팀원이 동일하게 프로비저닝된 환경에서 작업하는 경우, “내 컴퓨터에서는 잘 된다”는 말은 이제 맞는 말이어서 웃긴 것이 아니라, 그냥 웃긴 말이 됩니다.

Infrastructure as Code

개발자는 더 안정적이며 유지하기 쉽기 떄문에 모듈식 애플리케이션을 만듭니다. 이 아이디어를 IT 인프라에 적용하면 어떨까요? 시스템은 항상 변화하므로 적용은 어려운 일이 될 수 있습니다. 따라서 Atlassian은 프로비저닝에 코드를 사용하여 이 문제를 해결합니다.

IaC(Infrastructure as code)는 다시 프로비저닝하는 것이 수리하는 것보다 빠르며 더 일관적이고 재현 가능하다는 것을 의미합니다. 또한 프로덕션과 비슷한 구성으로 개발 환경의 변형을 쉽게 시작할 수 있습니다. 프로비저닝 코드를 적용하고 다시 적용하여 서버를 알려진 기준선에 포함시킬 수 있습니다. 버전 제어에 저장할 수 있고 테스트를 거쳐 CI(지속적 통합)에 통합하고 동료 검토를 할 수 있습니다.

제도화된 지식이 코드화되면 런북 및 내부 설명서의 필요성이 사라집니다. 반복 가능한 프로세스와 신뢰할 수 있는 시스템이 가능하게 됩니다.

소스 제어 및 공동 작업 코딩

코드에 대한 소스 제어가 중요합니다. 소스 제어 도구를 사용하면 코드를 여러 체인에 저장할 수 있으므로 변경 사항을 공유하여 모든 변경 사항을 확인하고 더 쉽게 협업할 수 있습니다. 프로덕션에 배포하기 전 변경 승인 보드를 기다리는 대신, 풀리퀘스트를 통해 동료 검토를 수행하여 코드 품질과 처리량을 개선할 수 있습니다.

풀리퀘스트가 무엇인지 물어보신다면, 풀리퀘스트는 리포지토리의 개발 브랜치에 푸시한 변경 사항을 팀에 알립니다. 그러면 팀에서 제안된 변경 사항을 검토하고 기본 코드 라인에 통합하기 전에 수정 사항에 대해 논의할 수 있습니다. 풀리퀘스트는 소프트웨어의 품질을 향상시켜 버그/인시던트가 줄어들고 운영 비용이 절감되며 개발 속도가 빨라집니다.

소스 제어 도구는 코드 개발 및 제공의 다양한 부분을 연결할 수 있는 다른 도구와 통합되어야 합니다. 이를 통해 기능의 코드가 프로덕션 환경에서 실행 중인지 확인할 수 있습니다. 인시던트가 발생하면 코드를 검색하여 인시던트에 대해 알아볼 수 있습니다.

지속적 통합은 하루에 여러 번 공유 리포지토리에 코드를 체크인하고 매번 테스팅하는 작업을 의미합니다. 이러한 방법으로 조기에 자동으로 문제를 감지하고, 가장 처리하기 쉬운 시점 문제를 해결하며, 가장 빠른 속도로 사용자에게 새로운 기능을 제공할 수 있습니다.

풀리퀘스트를 통한 코드 검토에는 브랜치가 필요하며 아주 인기가 높습니다. DevOps North Star는 개발 속도를 낮추지 않으면서 브랜치의 수를 줄이고 테스트의 엄격함을 유지하는 워크플로입니다.

개발 브랜치에 테스트를 자동으로 적용하고, 브랜치 빌드가 성공하면 메인으로 푸시할 수 있는 옵션을 제공하는 도구를 찾아보세요. 단순한 통합으로 팀에서 실시간 채팅 알림을 받아 지속적인 피드백을 획득할 수 있습니다.

Bitbucket Pipelines가 테스트에서 프로덕션까지 코드를 자동화하는 데 어떻게 도움이 되는지 알아보세요.

자동 테스트

테스트 도구는 예비 테스트, 테스트 관리, 오케스트레이션을 포함한 다양한 요구와 기능을 포괄합니다. 그러나 DevOps 도구 체인의 경우 자동화는 필수적인 기능입니다. 자동화된 테스트는 장기적으로 개발 속도와 테스트 주기를 가속해 시간이 지날수록 이점을 제공합니다. 또한 DevOps 환경에서는 '인식'이라는 측면에서 자동화가 중요성을 갖습니다.

테스트 자동화는 초기에 자주 수행하면 소프트웨어 품질을 높이고 위험을 줄일 수 있습니다. 개발 팀은 UI 테스트, 보안 검사 또는 부하 테스트와 같은 여러 영역을 다루는 자동화된 테스트를 반복적으로 실행할 수 있습니다. 또한 위험 영역을 식별하는 데 도움이 되는 보고서와 추세 그래프를 제공합니다.

위험은 소프트웨어 개발에서 있기 마련이지만, 예상할 수 없는 것이라면 완화할 수도 없습니다. 운영 팀의 요청을 들어 함께 조사할 수 있도록 하세요. 월보드를 지원하는 도구를 찾고 프로젝트에 참여한 모든 팀원이 특정 빌드 또는 배포 결과에 대해 의견을 남기도록 하세요. 블리츠 테스트 및 예비 테스트에 운영 팀을 쉽게 참여시킬 수 있는 도구가 있다면 더욱 좋습니다.

배포 대시보드

소프트웨어 출시 전 가장 어려운 부분 중 하나는 향후 릴리스를 위해 모든 변경 사항, 테스트 및 배포 정보를 한 곳으로 가져오는 것입니다. 릴리스 전 마지막으로 필요한 것은 상태 보고를 위한 긴 회의입니다. 이때 릴리스 대시보드가 필요합니다.

코드 리포지토리 및 배포 도구와 통합된 단일 대시보드를 포함하는 도구를 찾아보세요. 브랜치, 빌드, 풀리퀘스트 및 배포 알림에 대한 완전한 가시성을 한곳에서 제공하는 것을 찾아보세요.

자동화된 배포

모든 애플리케이션과 IT 환경에 적합한 자동화된 구축을 가능하게 하는 마법의 레시피는 존재하지 않습니다. 하지만 운영 팀의 런북을 Ruby 또는 Bash를 사용하여 명령줄에서 실행 가능한 스크립트로 전환하는 것은 일반적인 출발점입니다. 좋은 엔지니어링 관행이 중요합니다. 변수를 사용하여 호스트 이름을 제외하세요. 각 환경을 위한 고유한 스크립트 또는 코드를 유지 관리하는 일은 재미도 없거니와 주제에서도 벗어납니다. 유틸리티 메서드 또는 스크립트를 만들어 코드 중복을 방지하세요. 그리고 스크립트에 대해 동료 검토를 실시하여 상태를 확인하세요.

먼저 자동화를 가장 자주 사용하는 가장 낮은 수준의 환경으로 배포를 자동화한 다음 프로덕션 환경까지 자동화를 복제합니다. 다른 것보다도 이 연습이 환경 간의 차이점을 강조하고 표준화하기 위한 작업의 목록을 생성합니다. 또한 자동화를 통해 배포를 표준화하면 환경 내부와 환경 간의 “서버 드리프트”를 줄일 수 있습니다.

인시던트, 변경 및 문제 추적

DevOps 팀 간의 협업을 보장하는 열쇠는 동일한 작업을 확인할 수 있는 환경을 제공하는 것입니다. 인시던트가 보고되면 어떻게 합니까? 소프트웨어 문제와 연결되어 추적 가능합니까? 변경이 이루어지면 릴리스에 연결됩니까?

다른 시스템에서 인시던트와 소프트웨어 개발 프로젝트를 추적하는 것만큼 개발 팀과 운영 팀의 협업을 저해하는 것은 없습니다. 문제를 빠르게 파악하고 해결할 수 있도록 인시던트, 변경, 문제 및 소프트웨어 프로젝트를 하나의 플랫폼에 보관하는 도구를 찾아보세요.

애플리케이션 및 서버 성능 모니터링

자동화해야 하는 모니터링에는 서버 모니터링과 애플리케이션 성능 모니터링이라는 두 가지 유형이 있습니다.

시스템에 과부하를 테스하거나 API의 테스트를 보내는 것은 스팟 체크에는 적합합니다. 그러나 애플리케이션(및 환경)의 추세와 전반적인 상태를 이해하려면 연중무휴 24시간 데이터를 리스닝하고 기록하는 소프트웨어가 필요합니다. 지속적인 가시성은 성공적인 DevOps 팀을 위한 핵심 기능입니다.

그룹 채팅 클라이언트와 통합되는 도구를 찾아서 팀 회의실이나 인시던트에 대한 전용 공간으로 바로 알림을 전송하세요.

고객인 이미 빌드한 환경이 적합한지에 대한 의견을 갖고 있습니다. 해야 할 일은 경청입니다. 지속적인 피드백은 문화와 절차를 포괄하는 개념으로, 정기적인 피드백 수집과 함께 피드백에서 통찰력을 가져올 수 있는 도구를 필요로 합니다. 지속적 피드백 관행에는 NPS 데이터 수집 및 검토, 이탈 설문 조사, 버그 보고서, 지원 티켓, 트윗 등이 포함됩니다. DevOps 문화에서는 제품 팀의 누구나 사용자 의견에 액세스할 수 있습니다. 사용자 의견은 릴리스 계획부터 예비 테스트 세션에 이르는 모든 과정의 등불이 되어줄 수 있기 때문입니다.

자주 사용하는 설문 조사 플랫폼과 채팅 도구를 통합하여 NPS 스타일의 피드백을 받을 수 있는 애플리케이션을 찾아보세요. 실시간 피드백을 위해 Twitter 및/또는 Facebook을 채팅과 통합할 수도 있습니다. 소셜 미디어에서 오는 피드백에 대해 자세히 살펴보려면 과거 데이터를 사용하여 보고서를 가져올 수 있는 소셜 미디어 관리 플랫폼에 투자하는 것이 좋습니다.

피드백 분석 및 통합은 단기적으로 개발 속도를 느리게 만드는 것처럼 보일 수도 있지만, 아무도 원하지 않는 새로운 기능을 출시하는 것보다는 장기적으로 더 효율적입니다.

Atlassian은 개발 및 운영 팀이 즐겨 사용하는 도구와 통합할 수 있는 DevOps 도구 체인을 보유하는 것이 중요하다고 생각합니다. Atlassian에서 171개 이상의 선도적인 타사 벤더와 통합되는 DevOps의 플랫폼을 만드는 이유가 여기에 있습니다. 당사는 이를 통해 사용하는 도구 전반에서 사용자가 최상의 결정을 내릴 수 있도록 지원합니다. DevOps는 단일 벤더에서 가져오는 것이 아니라 구축하는 것입니다.

시작하려면 Atlassian의 DevOps 솔루션을 무료로 사용해 보세요.