2016 ahea 팀 해커톤 발표자료 발표자 정해균 주제 devops

1. DevOps
1

2. • DevOps 시작
• DevOps 소개
• DevOps 구성
• 자동화 도구
• 이제 무엇을 할
까?
2

3. DevOps 시작
3

4. DevOps 시작
• 의사소통, 협업, 융
합
• 신속히 생산
4

5. 혼동, 혼란
5

6. 개발의 이슈를 운영팀이 해결 해야 하는 상황이 옴
6

7. 1.범인찾기
2.욕하기
3.맘 상처 입기
4.문제 원인 분
석
5.문제 해결
7

8. 범인 찾기
8
누구의 잘못 인가? 불행의
시작

9. 욕하기
9
누구의 잘못 인가? 불행의
시작

10. 맘 상처 입기
10
누구의 잘못 인가? 불행의
시작

11. 문제 원인 분석
11
누구의 잘못 인가? 불행의
시작

12. 문제 해결
12
누구의 잘못 인가? 불행의
시작

13. Ops Dev
Dev VS Ops - 충돌
13

14. 결국엔…
14

15. Dev VS Ops - 충돌
• Dev : 고객에게 제공한 변경을 빠르게 보기 원함
• Ops : 안정성에 관심이 더 많음
15

16. Dev와 Ops간에 문제가 발생하는
이유
• 동기 : Dev 와 Ops 간에 서로 다른 목표 때문에 생김
• 프로세스 : 변경을 관리하는 방식, 실 서비스에 반영
하는 방식 및 관리하는 방식이 다름
• 도구 : Dev와 Ops가 서로 별도의 프로그램을 사용
함
16

17. DevOps란?
• 동기를 맞추고 프로세스와 도구에 대한 접근을 공유
하여 차이를 줄임
• 애자일 프랙티스를 운영으로 확장하여 더 강한 협업
및 소프트웨어 배포 프로세스 강화
• 문화, 사람이 프로세스보다 중요하며 도구보다 더 중
요함.
17

18. DevOps에서 중요한 것은 문화와 사람이며
그 다음이 프로세스와 도구
18

19. DevOps 가 아닌 것은?
• DevOps는 새로운 팀이 아님.
• DevOps는 새로운 일자리 이름이 아님.
• DevOps는 새로운 툴이 아님.
19

20. DevOps 소개
20

21. 전통적인 프로젝트 세팅
• 프로그래머 -> QA -> OPS
• OPS가 프로그래머, 테스터, QA에 항상 관여하는 것
은 아니지만 최종 결과는 OPS에서 진행이 됨.
• 분리된 팀, 공통의 언어가 없음.
• 서로간에 두려움이 있음.
21

22. 애자일 프로젝트 세팅
• 프로그래머와 QA가 함께 developer 가 되고 한 팀이
됨.
• 애자일에서 운영은 분리가 되어 있음.
• 운영의 경우 개발 팀에서 만든 소프트웨어를 배포함.
• Cycle time ( 아이디어에서 사용자에게 실제 서비스
하는데 걸리는 시간) 은 여전히 길어짐.
22

23. Dev + Ops
23

24. DevOps 의 핵심
• 가치와 목
적
• 프로세스
• 도구
24

25. 가치와 목적
• 서로간의 존중
• 공유된 목적에 대한 합의
• 공동의 소유권
(ownership)
• 가치의 공유
25

26. 프로세스
• 소프트웨어를 어떻게 개발하고 배포할지 정의하는
프로세스가 툴보다 중요함.
• 운영을 애자일 프로세스에 포함시키기.
• Dev와 Ops 간에 동일 프로세스를 공유.
• 통합된 프로세스를 통해서 cycle time 을 줄임.
26

27. 도구
• 프로세스가 도구보다 중요하지만 도구는 여전히 중
요함.
• DevOps의 능률은 자동화에 의존함.
• 빌드 시스템.
• 모든 단계에서 자동화된 적절한 도구가 필요함.
27

28. DevOps 구성
28

29. DevOps 구성하기 - 측정
지표
• Dev와 Ops간에 가장 중요한 측정지표는 cycle time.
전통적인 측정기준 애자일 측정 기준
29

30. DevOps - 변경
• 변경은 Dev와 Ops 간에 사용할 수 있는 유용한 지표
임.
30

31. DevOps 구성하기 - 흐름 개선하
기
• batch size 를 줄이는 것이 중요해짐 : batch size는
새로운 버전으로 올리기 전에 완료해야 할 변경 또는
작업량의 크기.
• 더 적은 변경사항(batch size)을 자주 배포하는 것이
중요함.
31

32. 자동화 도구
32

33. 이상적인 프로젝트란?
• 티켓 관리 시스템에 이슈 등이 집약되어 있다.
• 버전 관리 시스템을 이용.
• 반복 검증 가능한 CI 시스템을 도입
• 환경의 영향을 최소화하고 항상 배포 가능 상태로 둔다.
• 모두 기록해서 추적 가능하게 한다.
33

34. 지속적 통합(Continous
Integration)
• CI란?
• 통합이란 빌드, 테스트를 실시하는 프로세스를 말하며 이러한 통합 프로세스를 상시로 실시하는 것
을 CI 라고 함.
• 통합을 지속적으로 수행하는 것이 CI
• 원래 CI는 애자일 개발 방법의 하나로, 익스트림 프로그래밍 방법론으로 고안되었음.
• 가치 있는 소프트웨어를 고품질로 신속하게 전달하는 것을 목표로 하는것.
• 애자일 개발 중에서도 가장 기본이자 핵심 방법론임.
• 통합 작업을 미루지 말고 개발 중에라도 실시해서 소프트웨어 개발의 복잡성을 제거 하자는 것.
• 왜 CI 같은 방법론이 요구되는 걸까?
• 비용 면에서의 이점
• 시장 변화 속도
• 속도와 품질 둘 다 확보
34

35. CI 에 필요한 것
• 버전 관리 시스템 : subversion, Git
• 빌드 도구 : make, Scons, Ant, Maven, Gradle, Rake
• CI 도구 : Jenkins, Travis CI
35

36. 이제 무엇을 할까?
36

37. 우리의 문제는 무엇인가? 무엇을 할
것인가?
• 큰 이야기
• 같은 목적을 향해 달려가고 있는가?
• 같은 프로세스를 사용하고 있는가?
• 같은 도구를 사용하고 있는가?
• 작은이야기 1
• 도구부터 접근하기
• 공통의 배포 프로그램, 워크플로우 프로그램 사용
• QA / Staging 환경을 구축해보기
• 작은 이야기 2
• 오늘 해커톤을 통하여 효과를 검증해 보기(만들고 측정하고 배우기)
37