안녕하세요. 오픈소스컨설팅 아틀라시안팀입니다.

요즘 많은 고객사, 필드에서는 Agile, ALM, DevOps 문화 구축 후 CI/CD를 구축하고 준비하고 있습니다.

CI/CD Step by step을 소개 하겠습니다.

CI/CD란?

CI(Continuous Integration) 지속적인 통합을 의미합니다.

훌륭한 개발A팀 기능 100개와 개발B팀 기능 100개가 통합 된단다고 상상해보세요.

좋은 기능 200개가 될까요?

S/W 통합은 눈에 보이지 않는 복잡한 일입니다.

자동화된 도구로 자주 Build, Test로 S/W의 높은 품질을 유지해야 합니다.

CD(Continuous Delivery or Continuous Deploy)란?

높은 품질의 S/W를 개발서버, 운영서버에 배포하는 과정을 사람 손으로 한다면

시간, 비용, 실수가 발생합니다. Java Legacy System을 운영하는 조직 중에는

빌드 결과 class파일만 교체하는 경우도 있습니다. (신규 개발인데 이렇게 하고 계신가요? 저희한테 빨리 연락주세요)

엑셀 파일에 class파일 리스트 받고.. 

자동화된 배포 시스템은 시간, 비용, 실수를 방지하고 팀이 더 빠르게 개발, 빌드, 배포를 할 수 있게 해줍니다.

비즈니스팀, 기획, 디자인, 개발, 운영팀은 자동화된 빌드, 배포 시스템으로 민첩함을 유지하고

서비스를 시장에 높은 품질의 소프트웨어를 출시할 수 있습니다.

저희는 Atlassian 제품으로 요구사항 접수부터 이슈 트래킹, 문서 협업, 저장소, 빌드/배포 모든걸 구현하는 방법을 소개합니다.

Atlassian은 전세계에서 유일하게 ALM, DevOps, Agile을 구현할 수 있는 모든 솔루션이 있습니다.

Atlassian 제품으로 사용했을 때 장점은 관리의 편리성(UI가 비슷합니다.)과 각 부서별 동일한 솔루션 사용으로 소통비용 감소입니다.

<그림. CI/CD 구성도>

오늘은 Jira Service Desk 부터 Bamboo 까지 Step by step으로 진행해 보겠습니다.

하지만 스텝에 정답은 없습니다. 우리 조직에서 ‘이렇게 하면 좋겠다’를 적용, 프랙티스, 점진적 발전 모델이 좋은 사례가 될거에요.

<그림. 소프트웨어의 관리는 생명체와 같아서 끊임없는 관리가 필요합니다.>

Actor 

Actor를 설정해서 이해관계도 같이 설명해 보겠습니다.

내부 또는 외부 고객, 현업

불편함, 문제를 갖고 있습니다.

Product Owner, Project Leader

프로젝트 전체 일정, 계획, 성과등을 관리합니다.

개발팀

문제를 해결하거나 새로운 무언가를 일정에 맞춰 개발합니다.

일정, 사람은 정해졌으니 해야 할 일을 효율적으로 운영하기 위해서 애자일 방법론을 사용하곤 합니다.

보안, 운영팀

서비스, 인프라, 보안 등 어제도 문제가 없었고, 오늘도 문제가 없고, 내일도 문제가 없도록 운영하는 운영팀 입니다.

고객, PO(Product Owner), Dev, Test, Ops, 보안팀 역할을 설정했습니다.

IT서비스를 기획, 개발, 운영하는데 필요한 팀간의 사일로를 방지하고 현업하는지 알아보겠습니다.

요구사항 접수, 서비스 기획 

 고객께서는 Jira Service Desk 또는 Jira Software로 요구사항을 요청할 수 있습니다.

방법1. Jira Service Desk  

Jira Service Desk는 친숙하고 쉬운 UI를 제공합니다. 외부, 내부 고객에게 제공하여 쉽게 요구사항 접수를 받을 수 있고

Confluence Space와 연결하여 유사 문제, 해결 방법 Page를 제공합니다. 문제 해결이 매우 빨라질 수 있습니다!

SLA(Service-Level Agreement) 측정할 수 있는 항목도 있습니다. 자세한 사항은 SlideShare에 공유했습니다. (여기)

큰 특징은 고객은 라이선스가 필요 없습니다.

http://at.osci.kr (저희도 서비스 데스크 운영 중입니다. ^^ )

<그림. 서비스 데스크 포탈>

<그림. 검색어를 입력하면 관련 Confluence Page를 보여줍니다.>

• Jira Service Desk는 고객의 요청사항을 접수하는 포탈이 제공됩니다.
• 프로젝트별 포탈이 생성됩니다. 서비스 별로 프로젝트를 생성하고 포탈을 제공할 수 있습니다.

방법1. 요구사항 접수 

<그림. 요구사항을 접수하는 화면>

• 이슈(티켓) 유형을 선택하여 요청사항을 접수합니다.
• 입력하는 항목은 Jira Service Desk Admin께서 설정할 수 있습니다.
• Summary를 입력할 때 관련 Confluence 문서를 제공합니다.
• 서비스 팀은 반복적으로 동일하게 일어나는 문제 해결을 Confluence page(지식 베이스)로 제공함으로써 
• 고객이 문제 해결을 더욱 빨리 도와줍니다.

<그림. 요구사항 접수 – 티켓 생성 >

• 생성된 이슈(티켓) 상태를 포탈에서 확인할 수 있습니다.

 Product Owner또는 Project Leader는 서비스 데스크에 접수된 이슈를 확인합니다.

• 서비스 데스크에서 해결하지 못하는 문제는 개발팀에게 요청할 수 있습니다.
• Jira Service Desk에서 Jira Software Issue를 연결할 수 있습니다.

<그림. 서비스 데스크 프로젝트에서 개발팀 프로젝트 이슈 연결>

<그림. 서비스 데스크 이슈와 Jira Software 이슈 연결>

• 서비스 데스크로 접수된 요청사항은 고객의 언어로 이야기를 합니다.
• 하지만 개발팀은 개발언어, 엔지니어의 언어로 이야기합니다.
• 서비스 데스크는 중간에서 협업을 돕고 사일로를 방지합니다.
• 개발팀은 개발에 전념할 수 있겠죠?

방법2. Jira Software 

• Jira Software에서 바로 요구사항 접수를 할 수 있습니다.
• 하지만 고객도 Jira Software를 사용하기 때문에 라이선스가 필요합니다.
•  나도 라이선스 필요하다해~
• IT부서가 아닌 고객은 Jira Software UI가 어렵고 낯설게 느껴질 수 있습니다.
• 우리는 서비스를 자체적으로 기획하고 만드는 팀이라면
• Jira Software로도 충분합니다.

<그림. 이슈를 만들고 시작하세요>

일하는 방법 Scrum, Kanban 

• Jira Software는 Scrum board와 Kanban board를 생성할 수 있습니다.
• Agile 방법으로 일을 진행할 수 있습니다.
•  
• 개발팀은 이슈를 담당자에게 할당하고, 논의하고 산출물은 Confluence에 작성을 합니다.
• 팀에서 정한 Workflow에 따라서 이슈는 흘러가게 됩니다.
  • 예) 할일-기획-개발-테스트-배포신청-배포완료
• 이슈 오너쉽에 대해서 많이 궁금해 하시는데요 Kanban의 이슈 오너쉽을 예시로 들어보겠습니다.
  • 예)
    • 팀은 비즈니스팀, 개발팀, 운영팀이 있습니다.
    • 할일-기획-개발-테스트-배포신청-배포완료 Workflow 입니다.
    • 비즈니스팀에서는 할일, 기획 상태를 소유하고
    • 개발팀에서는 개발-테스트 상태를 소유하고
    • 운영팀에서는 배포신청-배포완료 상태를 소요할 수 있습니다.
    • 각 상태의 중요도 설정은 오너쉽이 있는 팀에서 합니다.
    • 비즈니스팀은 기획 이슈의 중요도를 자유롭게 정할 수 있습니다.
    • 비즈니스팀의 상태의 이슈를 개발팀에서 선택하여 개발로 옮긴 후부터 개발팀의 소유가 됩니다.

Jira Wrap up 

• Jira ServiceDesk, Jira Software 로 요구사항을 요청할 수 있습니다.
• 대외 서비스를 하거나 고객이 많다면 Jira ServiceDesk로 고객을 관리할 수 있습니다.
• 고객에 내부에 있거나 Jira Software를 같이 사용한다면 Jira Software로 충분합니다.
• 이슈(티켓, 일감)를 만드는 이유는 이슈 진행 상황을 공유하고 협업과 사일로 현상을 방지할 수 있습니다.
• 이슈는 시작과 끝이 있습니다. 그래서 설명에 산출물, 많은 정보는 Confluence에 남겨야 합니다.
• 설명에 포함된 단어는 검색이 어렵고 이슈가 해결 됐을 때 찾기 어렵기 때문입니다.

Jira Service Desk Case Study 

• Kakao
  • Jira Service Desk로 프로젝트 생성 요청을 받습니다.
  • 프로젝트 타입, 사용 스킴정보로 프로젝트를 생성합니다.
  • 프로젝트 생성은 자동화 기능을 직접 개발하셨습니다.
  • 내부 사용자들의 다양한 불편 사항을 서비스 데스크로 접수를 받습니다.
  • 평균 응답 시간은 30분이고 SLA 100%를 준수하고 있습니다.
  • Confluence Page를 연결하여 문제 해결을 빠르게 하고 있습니다.

팀 협업 – 지식 베이스 구축 

• 좋은 생각, 아이디어는 어디에 있을까요?
  우리 머릿속에 있습니다. 그 좋은 것들을 정리한 파일은 어디에 있을까요? 내 컴퓨터 또는 파일 서버에 있습니다.
  이러한 문제점을 해결하기 위해서 쉐어포인트, 구글닥스 등 문서 협업 도구를 사용하지만 이슈(work)와 연결하기는 쉽지 않습니다.
  Confluence는 Jira와 강력한 통합을 지원하면서 언제 어디서나 팀과 협업할 수 있습니다.
  

<그림. Confluence 구조>

Page 생성 

• 모든 사용자는 Page를 만들고 공유할 수 있습니다.
• (방법1) 최초의 요청사항을 Confluence로 시작해서 Jira로 시작할 수 있습니다.
• (방법2) 최초의 요청사항을 Jira로 시작해서 Confluence에 작성할 수 있습니다.
• 둘 중 더 좋은 방법은 무엇일까요? 정답은 실무자가 알고 있습니다.
• 프로세스가 흘러가는데 편하고 어색하지 않는 방법을 추천 드립니다. (감이 안오시면 다 해보는 걸로..)

<그림. 저도 Confluence에서 글을 작성하고 있어요>

• Create 버튼으로 Blank Page를 생성하거나
• Atlassian에서 제공하는 Template으로 Page를 생성할 수 있어요.

<그림. Atlassian에서 제공하는 Template>

• Template도 만들어서 정형화된 문서를 찍어낼 수 있어요.
• 양식을 고민하지 말고 GO

Jira Issue 연결 

• Confluence Page에서 Jira 이슈를 연결할 수 있습니다.

• 반대로 Jira issue에서 Confluence Page를 연결할 수 있습니다.

• Issue(work)은 일정, 진행 상태, 이해관계자 알림 등이 목적입니다.
• Page는 일이 진행되면 필요한 지식이 쌓이는 곳입니다.
• 목적에 맞게 일, 지식이 저장되고 사일로 현상을 방지하며 필요할 때 또 꺼내서 보기 쉽습니다.

Jira Issue Chart 

• Confluence에서는 Jira이슈 검색으로 차트로 표시할 수 있습니다.

Notification 

• Confluence Notification은 신문 구독과 같습니다.
• 보고싶은 내용을 개인 설정으로 받을 수 있어요.
• 
• 쉬운 정보 공유와 협업을 촉진 시키는데 이메일 알람이 큰 역할을 합니다.
• 
• 그 중 일간 업데이트 구독은 24시간 동안 변경 사항을 간단하게 정리해서 메일로 보내줍니다.
• 물론 공간, 페이지 권한이 있는 사용자들만 볼 수 있습니다.

Confluence Wrap up 

• Jira Issue(work)과 산출물을 연결하세요.
• Confluence는 최신 정보를 팀과 실시간으로 공유하고 발전 시킵니다.
• Jira Comment, Description에는 지식을 남기 마세요. 이슈가 릴리즈 되거나 완료되면 이슈 Comment 찾기 힘들어요.
• Confluence ↔ Jira Service Desk 연결로 문제 해결을 최전방에서 해결할 수 있습니다.
• 내 머릿속, 내 컴퓨터에 지식을 가두지 말고 Confluence에 남기세요.  

Bitbucket – 프로페셔널 팀을 위한 Git 솔루션 

Jira Issue – Branch 연결 

• Jira Software와 Bitbucket의 통합으로 Branch 생성을 Jira에서 할 수 있습니다.
  
  

Pull Request 승인 절차 

• Pull Request는 Master Branch에 Merge를 하기위한 절차입니다.
• 코드 리뷰를 통해서 품질을 향상 시키고 협업을 촉진 시킬 수 있어요
• Jira Software는 Branch History와 이슈를 연결하여 보는 최고의 툴입니다.
• 
• 
  Jira에서 분기점을 만들어 보세요.
  
• 
  Bitbucket 과 Application연결이 됐을 때 가능합니다.
  Master Branch에서 Issue key + summray로 생성되네요
  생성 후 Jira에서 Tracking 할 수 있습니다.
• 
• Jira에서 Git 상태를 확인하는게 중요합니다.
• 프로덕트 오너, 리더 등 매니저 그룹은 개발자보다 이슈에 더 포커싱이 되어 있습니다.
• Jira에서 이슈를 확인하고 코드를 확인하는 절차를 갖을 수 있습니다.
• 다른 동료 개발자들도 이슈와 코드를 Jira에서 이슈 상태와 함께 공유할 수 있기 때문에 협업 문화를 잘 구축할 수 있습니다.

• 개발이 끝나고 Pull Request를 생성하고 Reviewer를 지정하여 승인 절차를 받을 수 있습니다.
• PR(Pull Request)는 협업 문화, 코드 품질 향상 등 장점이 많습니다.

Wrap up 

• Jira에서 생성된 

Bamboo 

Bamboo Server는 프로페셔널 팀 이 지속적 통합, 배포를 위해 선택하는 제품입니다.

아틀라시안 제품과 강력하게 통합하여 자동화 빌드/배포 환경을 구축할 수 있습니다.

자동화의 목적은 빠른 빌드/배포를 자주하는 것 입니다. 

개발팀과 운영팀은 더 이상 배포는 두려움의 대상이 아닙니다.

Project 

Plans의 모음입니다. 논리적으로 관련된 계획을 쉽게 그룹화하고 식별 할 수 있습니다.

프로젝트 단위로 접근 권한을 설정하여 액세스를 쉽게 제어 할 수 있습니다.

• n개의 계획을 포함합니다.
• 프로젝트는 Reports를 제공합니다.
• Plan에 포함 된 권한을 설정할 수 있습니다.

<project settings>

• Project details
• Project permissions
• Plan permissions inheritance
• Bamboo Specs repositories
• Application links

Bamboo Project Admin을 설정하여 Admin이 Bamboo Plan, Repositories 접근 권한을 설정할 수 있습니다.

Application 개발자에게 한정적인 빌드, 배포 권한을 부여함으로써 Ops팀과 Dev팀의 차이를 줄일 수 있습니다.

Plan 

지속통합, 빌드 프로세스를 정의합니다.

• 기본적으로 하나의 stage로 구성되어 있지만, 여러개의 jobs을 여러 stage로 구성할 수 있습니다.
• 하나의 Repository를 사용하여 순차적으로 실행되는 하나 이상의 stage를 처리합니다.
• 기본 Repository를 지정합니다.
• 빌드가 트리거되는 방법과 프로젝트의 계획과 다른 계획 간의 트리거 종속성을 지정합니다.
• 빌드 결과에 대한 알림을 지정합니다.
  • 메일 또는 메신저
• Plan, jobs 설정 및 보기 권한을 설정할 수 있습니다.
• Plan variables를 설정할 수 있습니다.

<Create stage>

• stage를 추가할 수 있습니다.

Stage 

• 하나의 Plan에는 각 단계에 대한 stage를 정의할 수 있습니다.
• 예를들어, 컴파일 단계와 몇가지 테스트 단계, 배포 단계로 구성된 전반적인 Plan 빌드프로세스가 있을 수 있습니다.
• 기본적으로는 Default job이 있지만 여러 작업을 그룹화 하는데 사용할 수 있습니다.
• 여러 Agent에서 병렬처리 할 수 있습니다.
• 다음 Stage를 처리하기 위해서는 모든 작업을 성공적으로 완료해야 합니다.

Job 

• Plan 내의 단일 빌드 단위입니다.
• 하나 이상의 작업을 Bamboo Agent로 순차 또는 병렬 처리할 수 있습니다.
• 작업이 수행되는 순서를 제어합니다.
• job에 각 tast가 필요한 값으로 agent를 선택적으로 실행할 수 있습니다.
• artifacts를 생성하여 stage가 실행될 때 사용할 수 있습니다.

Deployment projects 

• 배포 프로젝트의 계획을 쉽게 만들 수 있습니다.

<빌드 배포 전략 예시>

• 배포는 다음을 포함하는 컨테이너 입니다.
• Development, Staging, Production과 같은 물리적 환경을 나타냅니다.
• 배포 중인 실제 소프트웨어 artifacts를 나타내는 릴리즈 – 릴리즈를 구성하는 이슈, 및 커밋 내역을 포함하고 있습니다.
• Plan의 통합 빌드, 배포를 workflow로 정의할 수 있습니다.

마무리 

요즘 DevOps 의 기술적인 부분인 CI/CD는 많은 관심을 받고 있습니다. 많은 자본과 인력을 가진 회사가 항상 좋은 소프트웨어를 누구보다 더 빠르게 만들 수 있을까요?

요즘 많은 스타트업들이 적은 자본과 인력으로 많은 서비스를 내놓고 있습니다. 우리는 비용 절감을 이야기하지 않습니다. 덩치가 커진 회사는 민첩함을 잃고 부서의 성과에 집중하게 됩니다.

DevOps, CI/CD, Agile 등은 팀에게 민첩함을 부여하고 공통된 성과에 집중하도록 합니다. 그러기 위해서는 문화, 기술의 변화가 필요합니다.

짧은 글로는 시작하기도 힘들어요 책을 수십 권 읽어도 시작하기 힘들어요. 많은 시행착오와 노하우를 갖고 있는 파트너가 필요합니다.

조직 문화와 기술에 변화를 갖는데 어려움을 갖고 계신다면 커피 한 잔 어떠세요?

atlassian@osci.kr 

감사합니다.