Experience CI/CD in the embedded device development process.

1. 임베디드 개발 프로세스 상에서의
CI/CD 경험

2. 소개
정재준
인스랩 CxO
Cloud Native, Digital Transformation,
Microservices, DevOps, IoT
비즈니스 발굴/기획, 제안, project Manager, 개발 환
경 혁신 컨설팅, CI/CD, Test automation 등
임베디드 개발(DVD, Navigation), 테스트 자동화 도구 개
발, Project Manager, Test Manager 품질 프로세스
혁신 컨설팅

3. 이런 것들의 이야기
•생산성과 품질
•임베디드 디바이스 개발
•개발 및 품질
•개발 환경을 이루는 도구들
•개발 문화

4. 누군가의 관심사
•어떻게 하면 안정적인 품질의 제품을 빠르고 싸게 만들 수 있나?
•품질
•속도
•비용
속도
품질
이 영역은 없겠죠?
엄청난 비용
의료/항공 등
특정 영역
사업적 이유

5. C-Level
생산성
품질
비용
측정
환경
문화
•항상 개발은 지연된다
•품질의 변화가 심하다
•개발 비용을 줄이고 싶다
•개발자는 뭐하고 있나
•자율과 통제, 고민이다

6. 임베디드 개발 과정
요구사항
상품기획
영업
시장(고객)
개발기획
개발리더
개발팀장
ES WS TP1 TP2
HW Timeline
스펙 선정
부품선정
하드웨어 설계
아트워크
PP1 PP2 MP1 MP2
SW Timeline
Bring Up(BSP, Kernel, Device Driver)
하드웨어에 최초 소프트웨어를 올리는 과정
출시
Middleware Application
설계 구현 테스트
Test Timeline
개발자
Deliver to QA Deliver to customer

7. 임베디드 개발 과정
요구사항 출시
설계 구현 테스트
Feature
Quality
요구사항
설계
구현
테스트
SW Timeline
새로운 보드(하드웨어)가 나왔을 때 품질은 보장되지 않음

8. 왜 그런가 - SW
기능1 기능2
UI UI
Mid Mid
DD DD
OS
•잘못된 아키텍처
•레이어링, 순환참조, 강한 의존성
•기능 중심의 개발로 인해 전체 아키
텍처에 대한 고민 부족
•하드웨어가 변경이 되면 DD,
Mid, UI까지 수정 필요
•협업의 문제(조직 및 개인)
•미래가 없는 플랫폼

9. 왜 그런가 - 조직
상품기획
영업
시장
개발기획
개발리더
개발팀장
개발자
개발팀장
개발자
개발팀장
개발자
제품
품질

10. 왜 그런가 - 조직
시장
제품
상품기획
영업
개발기획
개발팀장
개발리더
개발자
개발리더
개발자
개발리더
개발자
품질

11. 왜 그런가 - 환경
•제품 중심의 사고
•제품 출시 우선, 제품 출시일에 맞춘 임시 방편의 개발
•플랫폼이라고 말하지만 제품임
•경험의 잘못된 적용
•고생했던 영웅담
•경험은 영웅의 기억에만 존재하고 전승되지 않음
•SW 개발자에게 집중된 업무, 복잡한 의사소통 구조
•개발자의 시간은 리소스 또는 비용이라고 생각하지 않음

12. 개선 계획
•현황 조사
•CI/CD
•조직과 프로세스
•협업과 도구
•개발 문화

13. 현황 조사
•외부조직(영업, 상품기획, 개발기획)
•부정확한 요구사항
•기획 부서의 모호한 역할
•개발 조직
•최신 소스코드를 사용하지 않음. 빌드가 안되 테스트 할 수 없고 안정적으로 동작하지 않기 때문에 개발자는 서로 다른 버전의 소스코
드로 개발
•저장소는 개발팀의 임시 저장소. 안정적이지 않은 코드를 중앙 저장소에 반영
•빌드 시스템은 존재하지만 빌드 성공률 60% 정도이고 이를 통제하지 않음
•품질 조직
•개발 단계에서의 품질을 확보하기 위한 움직임이 있으나 전통적인 테스트 방법을 유지
•요구사항에 대한 분석 미비. 경험적 테스트 기법을 사용함

14. CI/CD - 빌드(Build)
•무형을 유형으로 바꾸는 행위, 구슬이
서말이라도 꿰어야 보배
•측정(테스트)이 가능하도록 한다
•현재 상태를 확인할 수 있다
•상태가 확인된 후에야 코드는 가치
를 갖게 됨
•지속적인 빌드와 테스트가 가능한
상태로 환경을 구성하는 것이 1차 목표
요구사항 구현 테스트
Difference
=
Quality
Doc, Code Exec.
Build

15. CI/CD - Gate Keeping
SVN
Pre-
commit
Commit
Jenkins
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
OK Fail
Reject
Commit
OK
⊿ code Daily/Release
SVN Pre-commit hook
•Build 성공 전까지는 Commit Pending
•개발자는 모든 빌드(향지, 보드 등)가 성공해
야 자신의 코드가 반영이 될 수 있음
•개발자 반발

16. CI/CD - Gate Keeping
Git
Forked
Repo.
Official
Repo.
Jenkins
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
Nodes
OK
Fail
Push
Merge
Daily/Release
Git forking workflow
Pull Request
Code
•Build Team에 서버 리소스 투입
•다양한 빌드 작업의 수행
•빌드및 저장소 관리 정책 수립
•Commit Reject 권한 부여
•빌드 성공률 향상 98%
•빌드 시간의 감소
•최소한의 깨끗한 저장소 유지
•테스트가 가능한 상태
•Reject을 통해 마인드 변화
Reject
Image
Repository

17. CI/CD - Test & Report
-1 day 오후
today 09:00
오전 테스트 & Report
today 15:00
오후 테스트 & Report
15:00~09:00 09:00~15:00
develop develop
develop
weekly
Weekly 테스트 &
Report
•가능한 가장 적은 코드 변경을 대상으로 테스트 수행
•Build 주기에 따라서 테스트의 Depth, Range 변경하여 수행
Release
develop
Release 테스트 &
Report

18. CI/CD - Test 확대
Downloader
•Test Server & auto downloader를 테스트 자동화
•저장소가 안정화되면서 다양한 테스트를 수행
•테스트 결과를 토대로 현재 코드 상태 및 개발 상황을 확인
Jenkins Test Server
Test
Target
build Image
Static
Analysis
Code
Review
Repo
Test
Coverage
Report
Test
Target
Test
Target
Coding Rule
commit log
Test Case
Test Script

19. CI/CD - 생각
•Build가 없는 개발은 공허하다
•지속적인 통합과 테스트 그리고 배포를 통해서 테스트가 가능한 상태의 코드를 유지할
필요가 있다
•CI/CD는 다양한 테스트로 이어질 수 있으며 테스트 결과는 개발의 현재를 보여 준다
•잘 구성된 CI/CD 시스템은 개발팀의 힘이자 개발 문화를 개선하는 지렛대이며 위
험 요소이다
•시스템을 통한 자동화는 매력적이지만 꼭 필요한 곳에만 구성한다
•테스트는 필요하고 항상 부족하고 아쉬운 지점이다

20. 조직과 프로세스
•프로세스는 문서에, 실제로는 적용되지 않는 문제
•개발팀에 부여되어 있는 많은 역할 문제
•개발팀 내에서의 정보 공유 문제
•실제 개발에 참여하는 개발자 문제

21. 조직과 프로세스 - 조직
PL PL
PL
Team
Leader
Team
Leader
Team
Leader
Dev Leader
•복잡한 의사소통체계
•팀리더의 개발 지식
•말만하는 고참 개발자
•집중된 개발 업무
•배타적인 협업
외부조직
개발조직

22. 조직과 프로세스 - 조직
PL PL
PL
Team
Leader Team
Leader
Dev Leader
외부조직
개발조직
Team
Leader
PM SDET
SDET : Software Development Engineer in Test

23. 조직과 프로세스 - 조직
•개발팀 개편, 조직 신설과 프로세스 구축 - CI/CD를 더 가치있게 하기 위한 개편
•PM조직 신설
•요구사항과 일정 및 주요 이벤트에 대한 관리
•복잡한 의사소통 구조를 개선
•SDET조직 신설
•다양한 테스트 확대 및 자동화
•테스트 케이스의 개발
•테스트 단계별로 품질 현황에 대한 분석

24. 조직과 프로세스 - 프로세스
요구사항 구현 Commit Push Build QA Test
요구사항 구현 Commit Push
Build &
Gate Keeping
Test
Release
Release
Committee
Report
QA Test
Report
이벤트 주기
Release
이벤트 주기
push, Daily, Weekly

25. 조직과 프로세스 - 생각
•조직문제는 언제나 정치적이다
•어떤 조직이든지 비생산적인 존재가 있다
•기술에서 멀어진 팀장(고참)은 팀에 부하를 준다
•프로세스는 항상 단순하게 할 필요가 있다
•협업이 없는 R&R은 항상 책임문제를 동반한다
•자동화된 프로세스는 어떤 힘을 갖는다
•사람을 움직이는 것이 가장 힘들다

26. 협업과 도구
Word
Excel
PPT
AAA_HLD_20171216_v0.8_홍길동.doc
AAA_seq-diagram_20171210_v0.1_임꺽정.ppt
2017년 xxx 모델 진행상황_20171217_상무님보고_b-team.xls
TP1차_주요버그리포트.xls
버그 리포팅 시스템 문서 공유 시스템 Repository
2017년 xxx 모델 진행상황_20171217_전무님보고.ppt
협업
•정보 공유
•커뮤니케이션
•공동 작업
•회의
•보고

27. 협업과 도구
Project
Management
Excel JIRA
Documentation Word
PPT
WiKi
(Confluence)
Repository SVN Git
Build No Policy CI/CD
visibility
status
Traceability
Responsibility
Easy Create
Easy share
Knowledge
Search
Flexible Policy
Easy CI
Various workflow
Gate keeping
Test
Quality

28. 협업과 도구
•개발 환경을 구성하는 도구의 변경
•Top down 방식으로 한번에 변경
•급격한 변화, 시행 착오, 많은 불만 (특히 저장소, CI)
•이전 도구의 불만족, 새로운 도구에 대한 교육 및 적응 시간 필요
•개발자의 지지, 설득
•관리자의 도구 사용에 대한 목적 인지와 학습
•적절한 도구의 선정과 개발자의 지지는 보다 빠른 개발 환경 개선에 도움

29. 협업과 도구
•명과 암
•개발자 업무량이 보이고 일이 많은 개발자는 할당된 이슈를 근거로 업무 분배 요청 가능
•개발자는 자신의 시간을 스스로 조정하기 어려워짐
•모든 개발 업무(회의, 커뮤니케이션 등)에 대한 고민
•개발팀의 업무 진척도와 품질 상태가 파악됨
•도구를 측정 또는 평가의 지표로 사용하려는 누군가
•도구의 효과적 사용을 위한 또 다른 규칙의 등장
•손쉬운 문서 생성 하지만 문서의 품질은 각양 각색
•지식의 집중 및 공유 활성화 (회사 내 Stack overflow)

30. 협업과 도구 - CI/CD
JIRA
Issue #1
Issue #2
Issue #3
Issue #4
Repository
Jenkins Test Automation
Wiki
Release Note
Test Report
Binary Repository
Tech. Document
협업 도구들과 CI/CD의 연계로 프로세스 자동화 지향

31. 협업과 도구 - 생각
•도구보다는 협업이 우선이다
•협업이 약할 수록 도구에 의존하는 경향이 있다
•도구는 사람을 편하게 해야하지만 모두를 만족 시킬수는 없다
•자동화는 일거리를 줄여주지만 모든 것을 자동화할 수 없다
•비용이 많이드는 자동화는 잘 선택해서 진행한다
•잘 구성된 도구들은 개발 문화 변화에 Trigger 가 될 수 있다

32. 개발 문화
문화란
“자연 상태에서 벗어나 일정한 목적 또는 생활 이상을 실현하고자 사회 구성원에 의하여
습득, 공유, 전달되는 행동 양식이나 생활 양식의 과정 및 그 과정에서 이룩하여 낸
물질적ㆍ정신적 소득을 통틀어 이르는 말. 의식주를 비롯하여 언어, 풍습, 종교, 학문, 예술, 제도 따
위를 모두 포함한다.”
개발 문화란(패러디)
개발자 개인에서 벗어나 일정한 목적 또는 이상을 실현하고자 하는 회사 또는 팀으로 인해
습득, 공유, 전달되는 행동 양식이나 생활 양식의 과정 및 그 과정에서 이룩하여 낸
물질적ㆍ정신적 소득을 통틀어 이르는 말. 업무 수행을 비롯하여 소통, 정체성, 가치관, 기술, 조
직, 프로세스 따위를 모두 포함한다.

33. 개발 문화
사람
•오래된 회사, 조직일수록 문화의 변화는 어려움
•의지가 있는 몇 사람이 주도하지만 실패확률이 높음
•사람만 교육해서 바뀌지 않으며 많은 시간이 필요
•사람, 조직, 프로세스가 전방위 적으로 변화해야함
•그래도 사람이 먼저다
조직
프로세스
문화
개발 문화는 사람, 조직, 프로세스가 통합된 정신적, 물질적 결과물 -> 쉽게 변하지 않는다

34. 개발 문화
꼬리를 잡아 몸통을 흔든다
•CI/CD를 적용함으로써 변화를 시작
•적절한 도구를 도입하여 변화의 속도를 가속화
•CI/CD와 도구의 경험을 통해서 새로운 문화 도입

35. 여전한 문제
•CI/CD에 대한 지속적인 유지 관리
•Embedded 개발에서 CI/CD는 주류가 되기 어려운 현실
•CI/CD가 멈추면 난리가 나지만 적당한 가치부여가 되지 않음
•테스트 케이스의 개발은 누가하나
•쉽지 않은 소스코드 테스트
•테스트라고 하는 것들은 모두 하려고 하지 않음
•정책 또는 규칙
•각종 정책과 규칙들이 많아지고 이것들의 해석을 아전인수식으로 하며 책임회피의 수단이 됨, 또 다른 규칙의 탄생
•수직적 조직과 사고 구조
•전통적인 개발 조직일 수록 수직적 관계가 강함
•경직된 조직 문화는 구성원이 생각하는 사고의 폭을 좁게 만들고 수동적으로 변하게 한다

36. 사족
변화의 원인

37. 감사합니다