SlideShare uma empresa Scribd logo
1 de 78
Baixar para ler offline
VSTS와 Azure를 이용한 팀 프로세스 관리
발표자
• 이규원
• 오마이랩 CTO
• https://www.facebook.com/gyuwon.yi
• https://twitter.com/gyuwon_yi
• https://justhackem.wordpress.com/
• https://github.com/gyuwon/
오마이랩 기술 팀 소개
• CTO 포함 프로그래머 4인
• 시니어 2인/ 주니어 2인(신입 1인)
• 글로벌 Multitenant 호텔 상품 관리 서비스 개발 중
• Multitenant 서비스 개발 경험자 없음
• 제품 관리자(Product Manager) 없음
• 디자이너 없음
• 거대 경쟁사들
• 경영진의 빠른 출시 요구
• Startup이 아님
오마이랩의
소프트웨어 개발 도구
소프트웨어 개발 도구
• 화이트보드
• Visual Studio
• Visual Studio Team Services
• Office 365
• Microsoft Azure
화이트보드
• 쉽게 쓰고
• 쉽게 그리고
• 쉽게 지우고
• 쉽게 촬영하고
• 쉽게 공유
Visual Studio
• 통합 개발 환경
• 코딩
• 버전 관리
• 테스팅 도구
• 디버거
• 1997~
• Visual Studio Team Services 통합
• Microsoft Azure 통합
Visual Studio Team Services
• 통합 소프트웨어 개발 생명주기 도구
• Code
• Git
• Pull Requests
• Work
• Boards
• Queries
• Build and Release
• Test
• Wiki
• Test & Feedback
Office 365
• Exchange, Outlook, Excel, PowerPoint, OneNote
• Microsoft Teams
• Slack vs Teams
• Office Lens
• 화이트보드 촬영
• Planner
Microsoft Teams
• 협업 소통 도구
• Slack vs Teams
• Slack의 높은 마감 품질
• Teams의 다양한 기능
• 채팅/ 영상 통화/ 파일 저장소/ 위키
• 각종 서비스 통합
• Office 365 제품군
• VSTS 통합
Office Lens
일반 촬영 Office Lens
Microsoft Azure
• Platform as a Service
• Azure Resource Manager template
• Infrastructure as Code
• Continuous Deployment
• Key Vault
• Secrets
• Credentials
• Application Insights
• Monitoring
• Diagnostics
오마이랩의
비즈니스 시스템 개발 절차
비즈니스 시스템 개발 절차
• 비즈니스 도메인 분석
• 고수준 아키텍처 설계
• 중/ 장기 일정 계획
• 사용자 스토리 개발
비즈니스
도메인
분석
• 시장은 무엇인가?
• 핵심 비즈니스 흐름은 무엇인가?
• 시장이 요구하는 시스템인가?
• 시장은 시스템에 댓가를 지불할 용의가 있는가?
• 경쟁자는 누구인가?
• 우리는 적시에 시스템을 출시할 수 있는가?
고수준 아키텍처 설계
• 시스템의 전반적인 구조 조망
• 주요 구성요소 배치와 관계
• 핵심 비즈니스 프로세스
• 외부 노출 인터페이스(UI/ API)
고수준 아키텍처 설계 절차
촬영
업로드
가공
공유
공유
중/ 장기 일정 계획
• 소프트웨어 개발 일정 계획은 난제
• 아이디어는 쉽고
• 코드는 어려움
• 프로그래머 개인의 능력은 전문적이고 생산성 격차가 매우 큼
• 대부분의 비즈니스 결정권자들은 소프트웨어를 이해하지 못 함
• 게다가 대부분의 기술자들은 결정권자들을 잘 설득하지 못 함
• 비즈니스는 시스템 개발 일정을 필요
• 시장 흐름 및 투자 계획
• 제품 홍보와 영업
사용자 스토리 개발
• 사용자 스토리
• 사용자 입장에서의 기능
• 소프트웨어 가치 단위
• 사용자 스토리 개발 반복
• 사용자 스토리 작성
• 세부 설계
• 작업항목 도출
• 작업항목 진행 반복
• 피드백
• 사용자 스토리 평가
사용자 스토리 작성
• 최우선 고객 가치 선택
• 경쟁 제품 벤치마크
• 언어 선택
• Ubiquitous Language
• 명사 + 동사
• 인격/ 기능/ 가치
As a <role>
I can <capability>,
so that <receive benefit>
세부 설계
• 도메인 모델
• Ubiquitous Language
• 도메인 모델은 데이터베이스가 아니다.
• 데이터베이스는 도메인 모델의 상태를 영속시키는 도구
• 동사는 명사만큼 중요
• No Silver Bullet
• 확장성, 반응성, 복원성, 일관성, …
• 다양한 가치와 위험을 교차 평가해 합리적으로 결정
• 화이트보드를 이용해 논의 후 코드로 표현
• 코드와 가장 일관된 설계는 코드 자신
세부 설계 절차
촬영
업로드
{ code }
코딩
작업항목/
위키
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
작업항목 도출
• 가능한 작은 단위로
• UX 설계
• 메시지/ API 정의
• 상태 및 데이터베이스 설계
• 핵심 도메인 논리 개발
• 제약사항 추가
• UI 개발
• 기능 통합
• 코드 배치 여파와 작업자 스케줄 고려
작업항목 진행 반복
• 코딩
• 코드 리뷰
• 코드 배치
코딩
• 작업항목 소스코드 분기 생성
• 짝 프로그래밍
• 코드 작성과 테스트
• 1회 이상 커밋
• GitHub Flow와 유사한 흐름
• https://guides.github.com/introduction/flow/
• 배치와 master 분기 병합 순서가 다름
작업항목 소스코드 분기 생성
• 작업항목을 통해 분기 생성
[work item id]-[kebab-case-description]
388-unmapped-room-rates-api
422-replace-old-language
• 작업항목과 코드 연결
• 분기
• 커밋
• Pull Requests
• 빌드/ 배치
• 테스트
짝 프로그래밍
• 실시간 코드 리뷰
• 코드 검증
• 지식 공유
• 상향 평준화 촉진
• 기술 조직의 복원성 향상
짝 프로그래밍 생산성
각자 한 줄의 코드라도 더 작성
또는
제품의 이해와 기술 지식의 원활한 흐름
코드 작성과 테스트
• 또는 테스트와 코드 작성
테스트 주도 개발(Test-Driven Development)
• 테스트는 크고 작은 요구사항을 표현
자가 검증 요구사항
• 기대된 동작 구현이 최우선
테스트가 기대된 동작 여부를 판단
리팩터링(re factoring)
• 기능(논리, 데이터, 공용 인터페이스, …)이 아닌 코드 구조를 변경
• 현재의 코드는 미래의 코드에 영향을 미침
• 과거의 코드는 현재의 코드에 영향을 미침
• 한 번 쓰인 코드는 반드시 여러 번 읽힘
• 같은 동작을 기준으로 코드는 적을 수록 좋음
• 짧은 코드의 의미가 아님
• 불필요한 코드를 유지하는 비용은 낭비
• 리팩터링은 테스트 케이스의 검증에 기반
*Beck design rules(https://martinfowler.com/bliki/BeckDesignRules.html)
커밋
• 소프트웨어의 가장 중요한 지식 기반
• 하나의 작업항목은 하나 이상의 커밋을 가짐
• 과도하지 않은 범위 내에서 작은 크기를 지향
• 설명력 있는 커밋 메시지
• 팀에 대한 배려
커밋 메시지
• 변경 사항을 요약
• 코드로 표현하기 어려운 내용을 기재
• 공유된 작성 규칙
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://justhackem.wordpress.com/2018/01/30/writing-git-commit-messages-using-vscode/
• 작업항목 연결
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
커밋 메시지 사례 #1 – 한 줄 설명
Channel 연결 명령 API를 추가한다
work items: #175
커밋 메시지 사례 #2 – 제목/ 본문
Channel Connector RoomRate 목록 API 추가
1. 헤더에 있는 사용자 인증정보 검사
2. 사용자 정보로 호텔의 RoomRate 목록 리턴
work items: #373
커밋 메시지 사례 #3 – 작업 내용과 목적
라이프 사이클 메서드를 DidUpdate로 변경한다
- ComponentDidMount: 첫 렌더시에만 호출된다
- ComponentDidUpdate: props가 업데이트 된 후 호출된다
현재 form에서 채널 선택 필드의 변화를 지속적으로 감지하여 변화가 발생할
때 마다 props를 업데이트 하고 있다.
unmapped room rate 선택 필드는 채널 선택 필드에서 선택된 채널 id로
get 요청을 보내고 있기 때문에 채널 선택에 변화가 생길 때 마다 get 요청을
보내야 한다. 따라서 DidMount보다 DidUpdate가 더 적절하다.
수정한 코드에서는 DidUpdate에서는 업데이트 전 props와
업데이트 후 props를 비교하여 두 값이 다를 때만 get요청을 보낸다.
work items: #411
커밋 메시지 사례 #4 – 미해결 문제 기록
MapRoomRateToChannel 명령에 누락된 속성을 채운다
Service Facade가 Channel Management 도메인 모델에 MapRoomRateToChannel
명령을 전송할 때 Channel Room Rate의 Description 정보들을 채운다.
추가된 논리는 수동으로 테스트 되었으며 실패하는 기존 단위 테스트
케이스는 DemoDay-2를 준비하기 위해 우선 비활성화 한다. 다음 설계 무결성
이슈 고려와 함께 DemoDay-2 이후 Task #415 에서 복구될 계획이다.
* 설계 무결성 이슈
MapRoomRateToChannel 명령을 도메인 모델에 보내기 위해 Channel Room Rate
목록을 조회해 클라이언트가 보낸 정보에 포함되지 않은 정보를 채운다. 이
과정에서 명령의 잘못된 상태들을 검증하게 되는데 이것은 도메인 모델
논리로 볼 수 있다. 즉, Service Facade가 Channel Management 도메인 논리를
포함하는 구조로 원래의 주어진 책임을 벗어난다. 만약 이 책임을
Channel Management 도메인 API로 옮기려면 Channel Management는
Service Facade 요청에 포함된 정보로만 구성된 중간 단계의 명령 메시지를
정의해 Service Facade에 제공해야 한다. 두 선택지 중 빠르게 구현할 수
있는 전자를 우선 취하지만 충분한 고민 후 설계 변경을 고려해야 한다.
work items: #413
Visual Studio CodeLens – 작업항목/ 커밋
Blame (Annotate)
코드 리뷰
• Pull Requests
• 코드 검증
• 지식 공유
• master 분기 변경 권한은 CTO를 포함해 그 누구도 가지지 않음
• 오직 VSTS만 이 권한을 소유
Pull Requests 완료
제약조건
• 동료의 승인
• 작업항목 연결
• 모든 의견 해결
• 빌드/ 테스트 통과
코드 리뷰 사례 #1 – 간단한 기술 지식 질문
코드 리뷰 사례 #2 – 기술 지식 질문
코드 리뷰 사례 #3 – 설계 의도 질문
코드 리뷰 사례 #4 – 내부 설계 제안
코드 리뷰 사례 #5 – 엄격하지 않은 기술 제안
코드 리뷰 사례 #6 – 설계 오류 발견
코드 리뷰 사례 #7 – 관련 작업자 알림
코드 배치
• 지속 배치/ 배달(Continuous Deployment/ Delivery)
• Infrastructure as Code
• ARM 템플릿(Azure Resource Manager template)
• 응용프로그램 설정
• Azure Key Vaults
• 기능 테스팅
지속 배치/ 배달(Continuous Deployment/ Delivery)
Release
<< Production/Staging >>
Release
<< Q/A >>
Download Artifacts
ARM Deployment
Publish Apps
Functional Testing
(Manual Acceptance Testing)
Swap
Download Artifacts
ARM Deployment
Publish Apps
Functional Testing
(Manual Acceptance Testing)
Build
Unit Testing
ARM Deployment
Publish Apps
Functional Testing
Build
<< Dev >>
Dev Configuration Q/A Configuration Production Configuration
Build and Release
Azure Key Vaults
Infrastructure as Code
{ code }
Azure Resource GroupAzure Resource Manager template
단위 테스팅(Unit Testing)
Application
Code
Code
Code
Code
Unit
Test Case
Unit
Test Case
Unit
Test Case
Unit
Test Case
Unit
Test Case
Unit
Test Case
Unit
Test Case
Unit
Test Case
기능 테스팅(Functional Testing)
Apps
Lease ContainerEvent Hub
Dev/ Prod Resource Group
Functional Test Cases
Azure
CI/ CD Pipelines
Azure Storage Emulator
Visual Studio
IIS Express
SQL Server Express
Apps Lease Container
Event Hub
Local Resource Group
AzureLocalMachine
Local Visual Studio
수동 승인 테스팅(Manual Acceptance Testing)
• Q/A 담당자가 배포된 코드를 수동으로 검증
• VSTS Manual Testing
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
피드백
• VSTS
• Test & Feedback
• Azure
• Application Insights
• App Service Remote Debugging
Test & Feedback
• Capture
• Create
• Collaborate
Application Insights
• 응용프로그램 성능 관리
• 데이터 분석
• 오류 진단
• 분산 시스템 분석
• VSTS 통합
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
VSTS와 Azure를 이용한 팀 프로세스 관리
Wiki
오마이랩의
기술팀이 느끼는 개발 환경
팀원 피드백 #1(시니어)
TDD와 DDD 기반에 Agile한 방식으로 4명의
멤버가 상호 소통하며 작업
아직 기획자/ 디자이너/ PMO/ QA/ SA 등
존재하지 않아 멤버마다 사고의 유연성이 필요
팀원 피드백 #2(주니어)
• 이전 회사에서 인수인계 받은 코드에서 하나의 단어를 놓고 코드마다 다르게 사용해서 결과 값이
말도 안되게 나와 고생
• 단어에 대한 정의가 정확하다 보니 코드에서도 한눈에 알 수 있고, 어떤 것을 이해하지 못했는지
정확하게 파악할 수 있어서 질문자와 답변자 사이의 오해가 크게 줄어드는 효과가 발생
Ubiquitous Language
• 문법 검사 정도에서 끝나지 않는 코드 리뷰
• 개발자 모두가 코드 리뷰에 참여 하기 때문에 리뷰 하는 사람들이 코드의 의미를 정확하게 알 수
있도록 코드 하나 하나 신경 써서 작성하게 되는 효과가 발생하는 것을 경험 중
코드 리뷰
팀원 피드백 #3-1(신입 나부랭이-명확한 프로세스)
유저 스토리 도출 ->
워크 아이템 등록/ 할당 ->
코딩 -> 코드리뷰 -> 병합
작업 프로세스가
명확하기 때문에 지금
하는 일이 끝나면 뭘
해야 하는 지 알고 있다
그래서 뭘 할지 잘 몰라
안절부절 하고 있을
일이 별로 없다
팀원 피드백 #3-2(신입 나부랭이-코드 리뷰)
읽는 사람을 배려하기 위해 들이는 노력이 스스로에게도, 코드의
품질에도 긍정적인 영향을 준다는 것을 느낌
CTO가 매의 눈이라 코드 사이에 낀 먼지도 볼 것 같아, 커밋 하나 하나에
훨씬 신중
별도 요청 사항(“API에 식빵도 넣어줘!” 같은…?)도 코드 리뷰로 확인하기
때문에 커뮤니케이션 미스로 인한 master 브랜치 오염을 차단하는 효과
팀원 피드백 #3-3
신입 나부랭이
통합 툴 사용
입사 전에는 Slack, GitHub, GitHub Project,
Google Docs, Hangout를 사용
‘스위칭 리소스’라는 고급진 표현이 쓰이는데,
이거 켰다 저거 켰다 하는 게 정말 귀찮았음
다른 도구로 넘어갈 때 마다 사고가 초기화
되어 뭘 하려고 했는지 한 번 더 생각함
지금은 VSTS 위에서 모든 것이 해결되기
때문에 너무 편하고 사고 정지 횟수 감소
이 약은 먹어봐야 앎
팀원 피드백 #3-4
신입 나부랭이-배포 자동화
“배포알못인 저도 클릭 두 번이면 배포가 가능합니다!”
페어 프로그래밍
팀 구성원 피드백 #3-5(신입 나부랭이)
고맙습니다!
오마이랩 기술팀 채용 문의: recruit@ohmylab.com

Mais conteúdo relacionado

Mais procurados

모바일 개발 트랜드
모바일 개발 트랜드모바일 개발 트랜드
모바일 개발 트랜드Terry Cho
 
웹:앱 기술 동향
웹:앱 기술 동향웹:앱 기술 동향
웹:앱 기술 동향ssuser0e53c8
 
Process Oriented Architecture
Process Oriented ArchitectureProcess Oriented Architecture
Process Oriented ArchitectureuEngine Solutions
 
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 almuEngine Solutions
 
1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스Terry Cho
 
Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3uEngine Solutions
 
Querydsl 발표
Querydsl 발표Querydsl 발표
Querydsl 발표ssuserd717021
 
DDD 구현기초 (거의 Final 버전)
DDD 구현기초 (거의 Final 버전)DDD 구현기초 (거의 Final 버전)
DDD 구현기초 (거의 Final 버전)beom kyun choi
 
제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발Terry Cho
 
Jpa 쿼리 포함 자료
Jpa 쿼리 포함 자료Jpa 쿼리 포함 자료
Jpa 쿼리 포함 자료Hyosang Hong
 
도메인 주도 설계 - 6장 도메인 객체의 생명주기
도메인 주도 설계 - 6장 도메인 객체의 생명주기도메인 주도 설계 - 6장 도메인 객체의 생명주기
도메인 주도 설계 - 6장 도메인 객체의 생명주기JangHyuk You
 
온라인 게임과 소셜 게임 서버는 어떻게 다른가?
온라인 게임과 소셜 게임 서버는 어떻게 다른가?온라인 게임과 소셜 게임 서버는 어떻게 다른가?
온라인 게임과 소셜 게임 서버는 어떻게 다른가?Seok-ju Yun
 
2015 u engine and oce day 개회사겸 식순 소개
2015 u engine and oce day   개회사겸 식순 소개2015 u engine and oce day   개회사겸 식순 소개
2015 u engine and oce day 개회사겸 식순 소개uEngine Solutions
 
3. 마이크로 서비스 아키텍쳐
3. 마이크로 서비스 아키텍쳐3. 마이크로 서비스 아키텍쳐
3. 마이크로 서비스 아키텍쳐Terry Cho
 
빠르게훓어보는 Node.js와 Vert.x
빠르게훓어보는 Node.js와 Vert.x빠르게훓어보는 Node.js와 Vert.x
빠르게훓어보는 Node.js와 Vert.xTerry Cho
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos uEngine Solutions
 

Mais procurados (19)

About Programmer 2021
About Programmer 2021About Programmer 2021
About Programmer 2021
 
DDD Start Ch#3
DDD Start Ch#3DDD Start Ch#3
DDD Start Ch#3
 
모바일 개발 트랜드
모바일 개발 트랜드모바일 개발 트랜드
모바일 개발 트랜드
 
웹:앱 기술 동향
웹:앱 기술 동향웹:앱 기술 동향
웹:앱 기술 동향
 
Process Oriented Architecture
Process Oriented ArchitectureProcess Oriented Architecture
Process Oriented Architecture
 
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm
아키텍트대회 유엔진-장진영-Sw공학표준을 기반한 alm
 
1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스1. 아키텍쳐 설계 프로세스
1. 아키텍쳐 설계 프로세스
 
Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3Event storming based msa training commerce example add_handson_v3
Event storming based msa training commerce example add_handson_v3
 
Querydsl 발표
Querydsl 발표Querydsl 발표
Querydsl 발표
 
DDD 구현기초 (거의 Final 버전)
DDD 구현기초 (거의 Final 버전)DDD 구현기초 (거의 Final 버전)
DDD 구현기초 (거의 Final 버전)
 
제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발제13회컨퍼런스 조대협 서버사이드개발
제13회컨퍼런스 조대협 서버사이드개발
 
Jpa 쿼리 포함 자료
Jpa 쿼리 포함 자료Jpa 쿼리 포함 자료
Jpa 쿼리 포함 자료
 
Bounded Context
Bounded ContextBounded Context
Bounded Context
 
도메인 주도 설계 - 6장 도메인 객체의 생명주기
도메인 주도 설계 - 6장 도메인 객체의 생명주기도메인 주도 설계 - 6장 도메인 객체의 생명주기
도메인 주도 설계 - 6장 도메인 객체의 생명주기
 
온라인 게임과 소셜 게임 서버는 어떻게 다른가?
온라인 게임과 소셜 게임 서버는 어떻게 다른가?온라인 게임과 소셜 게임 서버는 어떻게 다른가?
온라인 게임과 소셜 게임 서버는 어떻게 다른가?
 
2015 u engine and oce day 개회사겸 식순 소개
2015 u engine and oce day   개회사겸 식순 소개2015 u engine and oce day   개회사겸 식순 소개
2015 u engine and oce day 개회사겸 식순 소개
 
3. 마이크로 서비스 아키텍쳐
3. 마이크로 서비스 아키텍쳐3. 마이크로 서비스 아키텍쳐
3. 마이크로 서비스 아키텍쳐
 
빠르게훓어보는 Node.js와 Vert.x
빠르게훓어보는 Node.js와 Vert.x빠르게훓어보는 Node.js와 Vert.x
빠르게훓어보는 Node.js와 Vert.x
 
Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos Private PaaS with Docker, spring cloud and mesos
Private PaaS with Docker, spring cloud and mesos
 

Semelhante a VSTS와 Azure를 이용한 팀 프로세스 관리

모바일, 클라우드, 웹 환경에 필요한 DB관리
모바일, 클라우드, 웹 환경에 필요한 DB관리모바일, 클라우드, 웹 환경에 필요한 DB관리
모바일, 클라우드, 웹 환경에 필요한 DB관리mosaicnet
 
청강대 특강 - 프로젝트 제대로 해보기
청강대 특강 - 프로젝트 제대로 해보기청강대 특강 - 프로젝트 제대로 해보기
청강대 특강 - 프로젝트 제대로 해보기Chris Ohk
 
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)Sungmin Kim
 
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해Terry Cho
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스Hee Jae Lee
 
성장하는 스타트업의 프로세스 개척기
성장하는 스타트업의 프로세스 개척기성장하는 스타트업의 프로세스 개척기
성장하는 스타트업의 프로세스 개척기DomainDriven DomainDriven
 
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016Amazon Web Services Korea
 
ALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsTaeyoung Kim
 
04 워터폴모델-개발프로세스
04 워터폴모델-개발프로세스04 워터폴모델-개발프로세스
04 워터폴모델-개발프로세스Andrew Sungjin Kim
 
개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2Daniel Lim
 
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재NAVER D2
 
테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션SangIn Choung
 
처음 시작하는 라라벨
처음 시작하는 라라벨처음 시작하는 라라벨
처음 시작하는 라라벨KwangSeob Jeong
 
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravel
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravelXECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravel
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravelXpressEngine
 
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브Atlassian 대한민국
 
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기 [아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기 iFunFactory Inc.
 
01.개발환경 교육교재
01.개발환경 교육교재01.개발환경 교육교재
01.개발환경 교육교재Hankyo
 
Build Team Foundation Architecture
Build Team Foundation ArchitectureBuild Team Foundation Architecture
Build Team Foundation Architecture준일 엄
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019devCAT Studio, NEXON
 
델파이 소스코드의재발견
델파이 소스코드의재발견델파이 소스코드의재발견
델파이 소스코드의재발견Devgear
 

Semelhante a VSTS와 Azure를 이용한 팀 프로세스 관리 (20)

모바일, 클라우드, 웹 환경에 필요한 DB관리
모바일, 클라우드, 웹 환경에 필요한 DB관리모바일, 클라우드, 웹 환경에 필요한 DB관리
모바일, 클라우드, 웹 환경에 필요한 DB관리
 
청강대 특강 - 프로젝트 제대로 해보기
청강대 특강 - 프로젝트 제대로 해보기청강대 특강 - 프로젝트 제대로 해보기
청강대 특강 - 프로젝트 제대로 해보기
 
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)
 
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
소프트웨어 개발 트랜드 및 MSA (마이크로 서비스 아키텍쳐)의 이해
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
 
성장하는 스타트업의 프로세스 개척기
성장하는 스타트업의 프로세스 개척기성장하는 스타트업의 프로세스 개척기
성장하는 스타트업의 프로세스 개척기
 
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
AWS와 함께하는 DevOps이야기 :: 박선용 :: AWS Summit Seoul 2016
 
ALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOpsALM과 DevOps 그리고 Azure DevOps
ALM과 DevOps 그리고 Azure DevOps
 
04 워터폴모델-개발프로세스
04 워터폴모델-개발프로세스04 워터폴모델-개발프로세스
04 워터폴모델-개발프로세스
 
개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2개발 생산성 향상 기법 V1.2
개발 생산성 향상 기법 V1.2
 
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
[네이버오픈소스세미나] egjs-view360 개발기 - 김희재
 
테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션테스트수행사례 W통합보안솔루션
테스트수행사례 W통합보안솔루션
 
처음 시작하는 라라벨
처음 시작하는 라라벨처음 시작하는 라라벨
처음 시작하는 라라벨
 
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravel
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravelXECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravel
XECon2015 :: [2-1] 정광섭 - 처음 시작하는 laravel
 
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브
Atlassian을 이용한 애자일 ALM 소개 / JIRA 프로젝트 예산 관리 - 커브
 
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기 [아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
 
01.개발환경 교육교재
01.개발환경 교육교재01.개발환경 교육교재
01.개발환경 교육교재
 
Build Team Foundation Architecture
Build Team Foundation ArchitectureBuild Team Foundation Architecture
Build Team Foundation Architecture
 
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
윤석주, 신입 게임 프로그래머가 되는 법 - 넥슨 채용 프로세스 단계별 분석, NDC2019
 
델파이 소스코드의재발견
델파이 소스코드의재발견델파이 소스코드의재발견
델파이 소스코드의재발견
 

Mais de Gyuwon Yi

Event sourcing spring camp 2017.public
Event sourcing spring camp 2017.publicEvent sourcing spring camp 2017.public
Event sourcing spring camp 2017.publicGyuwon Yi
 
Why you always fail with tdd
Why you always fail with tddWhy you always fail with tdd
Why you always fail with tddGyuwon Yi
 
CQRS - Show me the code
CQRS - Show me the codeCQRS - Show me the code
CQRS - Show me the codeGyuwon Yi
 
프로그래밍, 설계 그리고 패턴
프로그래밍, 설계 그리고 패턴프로그래밍, 설계 그리고 패턴
프로그래밍, 설계 그리고 패턴Gyuwon Yi
 
Unit testing
Unit testingUnit testing
Unit testingGyuwon Yi
 
Xamarin Forms, MVVM and Testing
Xamarin Forms, MVVM and TestingXamarin Forms, MVVM and Testing
Xamarin Forms, MVVM and TestingGyuwon Yi
 
Reactive Model-View-ViewModel Architecture
Reactive Model-View-ViewModel ArchitectureReactive Model-View-ViewModel Architecture
Reactive Model-View-ViewModel ArchitectureGyuwon Yi
 
Introduction to IoC Container
Introduction to IoC ContainerIntroduction to IoC Container
Introduction to IoC ContainerGyuwon Yi
 
Introduction to TPL
Introduction to TPLIntroduction to TPL
Introduction to TPLGyuwon Yi
 

Mais de Gyuwon Yi (10)

Event sourcing spring camp 2017.public
Event sourcing spring camp 2017.publicEvent sourcing spring camp 2017.public
Event sourcing spring camp 2017.public
 
Why you always fail with tdd
Why you always fail with tddWhy you always fail with tdd
Why you always fail with tdd
 
CQRS - Show me the code
CQRS - Show me the codeCQRS - Show me the code
CQRS - Show me the code
 
CQRS
CQRSCQRS
CQRS
 
프로그래밍, 설계 그리고 패턴
프로그래밍, 설계 그리고 패턴프로그래밍, 설계 그리고 패턴
프로그래밍, 설계 그리고 패턴
 
Unit testing
Unit testingUnit testing
Unit testing
 
Xamarin Forms, MVVM and Testing
Xamarin Forms, MVVM and TestingXamarin Forms, MVVM and Testing
Xamarin Forms, MVVM and Testing
 
Reactive Model-View-ViewModel Architecture
Reactive Model-View-ViewModel ArchitectureReactive Model-View-ViewModel Architecture
Reactive Model-View-ViewModel Architecture
 
Introduction to IoC Container
Introduction to IoC ContainerIntroduction to IoC Container
Introduction to IoC Container
 
Introduction to TPL
Introduction to TPLIntroduction to TPL
Introduction to TPL
 

VSTS와 Azure를 이용한 팀 프로세스 관리

  • 1. VSTS와 Azure를 이용한 팀 프로세스 관리
  • 2. 발표자 • 이규원 • 오마이랩 CTO • https://www.facebook.com/gyuwon.yi • https://twitter.com/gyuwon_yi • https://justhackem.wordpress.com/ • https://github.com/gyuwon/
  • 3. 오마이랩 기술 팀 소개 • CTO 포함 프로그래머 4인 • 시니어 2인/ 주니어 2인(신입 1인) • 글로벌 Multitenant 호텔 상품 관리 서비스 개발 중 • Multitenant 서비스 개발 경험자 없음 • 제품 관리자(Product Manager) 없음 • 디자이너 없음 • 거대 경쟁사들 • 경영진의 빠른 출시 요구 • Startup이 아님
  • 5. 소프트웨어 개발 도구 • 화이트보드 • Visual Studio • Visual Studio Team Services • Office 365 • Microsoft Azure
  • 6. 화이트보드 • 쉽게 쓰고 • 쉽게 그리고 • 쉽게 지우고 • 쉽게 촬영하고 • 쉽게 공유
  • 7. Visual Studio • 통합 개발 환경 • 코딩 • 버전 관리 • 테스팅 도구 • 디버거 • 1997~ • Visual Studio Team Services 통합 • Microsoft Azure 통합
  • 8. Visual Studio Team Services • 통합 소프트웨어 개발 생명주기 도구 • Code • Git • Pull Requests • Work • Boards • Queries • Build and Release • Test • Wiki • Test & Feedback
  • 9. Office 365 • Exchange, Outlook, Excel, PowerPoint, OneNote • Microsoft Teams • Slack vs Teams • Office Lens • 화이트보드 촬영 • Planner
  • 10. Microsoft Teams • 협업 소통 도구 • Slack vs Teams • Slack의 높은 마감 품질 • Teams의 다양한 기능 • 채팅/ 영상 통화/ 파일 저장소/ 위키 • 각종 서비스 통합 • Office 365 제품군 • VSTS 통합
  • 12. Microsoft Azure • Platform as a Service • Azure Resource Manager template • Infrastructure as Code • Continuous Deployment • Key Vault • Secrets • Credentials • Application Insights • Monitoring • Diagnostics
  • 14. 비즈니스 시스템 개발 절차 • 비즈니스 도메인 분석 • 고수준 아키텍처 설계 • 중/ 장기 일정 계획 • 사용자 스토리 개발
  • 15. 비즈니스 도메인 분석 • 시장은 무엇인가? • 핵심 비즈니스 흐름은 무엇인가? • 시장이 요구하는 시스템인가? • 시장은 시스템에 댓가를 지불할 용의가 있는가? • 경쟁자는 누구인가? • 우리는 적시에 시스템을 출시할 수 있는가?
  • 16. 고수준 아키텍처 설계 • 시스템의 전반적인 구조 조망 • 주요 구성요소 배치와 관계 • 핵심 비즈니스 프로세스 • 외부 노출 인터페이스(UI/ API)
  • 17. 고수준 아키텍처 설계 절차 촬영 업로드 가공 공유 공유
  • 18. 중/ 장기 일정 계획 • 소프트웨어 개발 일정 계획은 난제 • 아이디어는 쉽고 • 코드는 어려움 • 프로그래머 개인의 능력은 전문적이고 생산성 격차가 매우 큼 • 대부분의 비즈니스 결정권자들은 소프트웨어를 이해하지 못 함 • 게다가 대부분의 기술자들은 결정권자들을 잘 설득하지 못 함 • 비즈니스는 시스템 개발 일정을 필요 • 시장 흐름 및 투자 계획 • 제품 홍보와 영업
  • 19. 사용자 스토리 개발 • 사용자 스토리 • 사용자 입장에서의 기능 • 소프트웨어 가치 단위 • 사용자 스토리 개발 반복 • 사용자 스토리 작성 • 세부 설계 • 작업항목 도출 • 작업항목 진행 반복 • 피드백 • 사용자 스토리 평가
  • 20. 사용자 스토리 작성 • 최우선 고객 가치 선택 • 경쟁 제품 벤치마크 • 언어 선택 • Ubiquitous Language • 명사 + 동사 • 인격/ 기능/ 가치 As a <role> I can <capability>, so that <receive benefit>
  • 21. 세부 설계 • 도메인 모델 • Ubiquitous Language • 도메인 모델은 데이터베이스가 아니다. • 데이터베이스는 도메인 모델의 상태를 영속시키는 도구 • 동사는 명사만큼 중요 • No Silver Bullet • 확장성, 반응성, 복원성, 일관성, … • 다양한 가치와 위험을 교차 평가해 합리적으로 결정 • 화이트보드를 이용해 논의 후 코드로 표현 • 코드와 가장 일관된 설계는 코드 자신
  • 22. 세부 설계 절차 촬영 업로드 { code } 코딩 작업항목/ 위키
  • 26. 작업항목 도출 • 가능한 작은 단위로 • UX 설계 • 메시지/ API 정의 • 상태 및 데이터베이스 설계 • 핵심 도메인 논리 개발 • 제약사항 추가 • UI 개발 • 기능 통합 • 코드 배치 여파와 작업자 스케줄 고려
  • 27. 작업항목 진행 반복 • 코딩 • 코드 리뷰 • 코드 배치
  • 28. 코딩 • 작업항목 소스코드 분기 생성 • 짝 프로그래밍 • 코드 작성과 테스트 • 1회 이상 커밋 • GitHub Flow와 유사한 흐름 • https://guides.github.com/introduction/flow/ • 배치와 master 분기 병합 순서가 다름
  • 29. 작업항목 소스코드 분기 생성 • 작업항목을 통해 분기 생성 [work item id]-[kebab-case-description] 388-unmapped-room-rates-api 422-replace-old-language • 작업항목과 코드 연결 • 분기 • 커밋 • Pull Requests • 빌드/ 배치 • 테스트
  • 30. 짝 프로그래밍 • 실시간 코드 리뷰 • 코드 검증 • 지식 공유 • 상향 평준화 촉진 • 기술 조직의 복원성 향상
  • 31. 짝 프로그래밍 생산성 각자 한 줄의 코드라도 더 작성 또는 제품의 이해와 기술 지식의 원활한 흐름
  • 32. 코드 작성과 테스트 • 또는 테스트와 코드 작성 테스트 주도 개발(Test-Driven Development) • 테스트는 크고 작은 요구사항을 표현 자가 검증 요구사항 • 기대된 동작 구현이 최우선 테스트가 기대된 동작 여부를 판단
  • 33. 리팩터링(re factoring) • 기능(논리, 데이터, 공용 인터페이스, …)이 아닌 코드 구조를 변경 • 현재의 코드는 미래의 코드에 영향을 미침 • 과거의 코드는 현재의 코드에 영향을 미침 • 한 번 쓰인 코드는 반드시 여러 번 읽힘 • 같은 동작을 기준으로 코드는 적을 수록 좋음 • 짧은 코드의 의미가 아님 • 불필요한 코드를 유지하는 비용은 낭비 • 리팩터링은 테스트 케이스의 검증에 기반 *Beck design rules(https://martinfowler.com/bliki/BeckDesignRules.html)
  • 34. 커밋 • 소프트웨어의 가장 중요한 지식 기반 • 하나의 작업항목은 하나 이상의 커밋을 가짐 • 과도하지 않은 범위 내에서 작은 크기를 지향 • 설명력 있는 커밋 메시지 • 팀에 대한 배려
  • 35. 커밋 메시지 • 변경 사항을 요약 • 코드로 표현하기 어려운 내용을 기재 • 공유된 작성 규칙 https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://justhackem.wordpress.com/2018/01/30/writing-git-commit-messages-using-vscode/ • 작업항목 연결
  • 38. 커밋 메시지 사례 #1 – 한 줄 설명 Channel 연결 명령 API를 추가한다 work items: #175
  • 39. 커밋 메시지 사례 #2 – 제목/ 본문 Channel Connector RoomRate 목록 API 추가 1. 헤더에 있는 사용자 인증정보 검사 2. 사용자 정보로 호텔의 RoomRate 목록 리턴 work items: #373
  • 40. 커밋 메시지 사례 #3 – 작업 내용과 목적 라이프 사이클 메서드를 DidUpdate로 변경한다 - ComponentDidMount: 첫 렌더시에만 호출된다 - ComponentDidUpdate: props가 업데이트 된 후 호출된다 현재 form에서 채널 선택 필드의 변화를 지속적으로 감지하여 변화가 발생할 때 마다 props를 업데이트 하고 있다. unmapped room rate 선택 필드는 채널 선택 필드에서 선택된 채널 id로 get 요청을 보내고 있기 때문에 채널 선택에 변화가 생길 때 마다 get 요청을 보내야 한다. 따라서 DidMount보다 DidUpdate가 더 적절하다. 수정한 코드에서는 DidUpdate에서는 업데이트 전 props와 업데이트 후 props를 비교하여 두 값이 다를 때만 get요청을 보낸다. work items: #411
  • 41. 커밋 메시지 사례 #4 – 미해결 문제 기록 MapRoomRateToChannel 명령에 누락된 속성을 채운다 Service Facade가 Channel Management 도메인 모델에 MapRoomRateToChannel 명령을 전송할 때 Channel Room Rate의 Description 정보들을 채운다. 추가된 논리는 수동으로 테스트 되었으며 실패하는 기존 단위 테스트 케이스는 DemoDay-2를 준비하기 위해 우선 비활성화 한다. 다음 설계 무결성 이슈 고려와 함께 DemoDay-2 이후 Task #415 에서 복구될 계획이다. * 설계 무결성 이슈 MapRoomRateToChannel 명령을 도메인 모델에 보내기 위해 Channel Room Rate 목록을 조회해 클라이언트가 보낸 정보에 포함되지 않은 정보를 채운다. 이 과정에서 명령의 잘못된 상태들을 검증하게 되는데 이것은 도메인 모델 논리로 볼 수 있다. 즉, Service Facade가 Channel Management 도메인 논리를 포함하는 구조로 원래의 주어진 책임을 벗어난다. 만약 이 책임을 Channel Management 도메인 API로 옮기려면 Channel Management는 Service Facade 요청에 포함된 정보로만 구성된 중간 단계의 명령 메시지를 정의해 Service Facade에 제공해야 한다. 두 선택지 중 빠르게 구현할 수 있는 전자를 우선 취하지만 충분한 고민 후 설계 변경을 고려해야 한다. work items: #413
  • 42. Visual Studio CodeLens – 작업항목/ 커밋
  • 44. 코드 리뷰 • Pull Requests • 코드 검증 • 지식 공유 • master 분기 변경 권한은 CTO를 포함해 그 누구도 가지지 않음 • 오직 VSTS만 이 권한을 소유
  • 45. Pull Requests 완료 제약조건 • 동료의 승인 • 작업항목 연결 • 모든 의견 해결 • 빌드/ 테스트 통과
  • 46. 코드 리뷰 사례 #1 – 간단한 기술 지식 질문
  • 47. 코드 리뷰 사례 #2 – 기술 지식 질문
  • 48. 코드 리뷰 사례 #3 – 설계 의도 질문
  • 49. 코드 리뷰 사례 #4 – 내부 설계 제안
  • 50. 코드 리뷰 사례 #5 – 엄격하지 않은 기술 제안
  • 51. 코드 리뷰 사례 #6 – 설계 오류 발견
  • 52. 코드 리뷰 사례 #7 – 관련 작업자 알림
  • 53. 코드 배치 • 지속 배치/ 배달(Continuous Deployment/ Delivery) • Infrastructure as Code • ARM 템플릿(Azure Resource Manager template) • 응용프로그램 설정 • Azure Key Vaults • 기능 테스팅
  • 54. 지속 배치/ 배달(Continuous Deployment/ Delivery) Release << Production/Staging >> Release << Q/A >> Download Artifacts ARM Deployment Publish Apps Functional Testing (Manual Acceptance Testing) Swap Download Artifacts ARM Deployment Publish Apps Functional Testing (Manual Acceptance Testing) Build Unit Testing ARM Deployment Publish Apps Functional Testing Build << Dev >> Dev Configuration Q/A Configuration Production Configuration Build and Release Azure Key Vaults
  • 55. Infrastructure as Code { code } Azure Resource GroupAzure Resource Manager template
  • 56. 단위 테스팅(Unit Testing) Application Code Code Code Code Unit Test Case Unit Test Case Unit Test Case Unit Test Case Unit Test Case Unit Test Case Unit Test Case Unit Test Case
  • 57. 기능 테스팅(Functional Testing) Apps Lease ContainerEvent Hub Dev/ Prod Resource Group Functional Test Cases Azure CI/ CD Pipelines Azure Storage Emulator Visual Studio IIS Express SQL Server Express Apps Lease Container Event Hub Local Resource Group AzureLocalMachine Local Visual Studio
  • 58. 수동 승인 테스팅(Manual Acceptance Testing) • Q/A 담당자가 배포된 코드를 수동으로 검증 • VSTS Manual Testing
  • 61. 피드백 • VSTS • Test & Feedback • Azure • Application Insights • App Service Remote Debugging
  • 62. Test & Feedback • Capture • Create • Collaborate
  • 63. Application Insights • 응용프로그램 성능 관리 • 데이터 분석 • 오류 진단 • 분산 시스템 분석 • VSTS 통합
  • 69. Wiki
  • 71. 팀원 피드백 #1(시니어) TDD와 DDD 기반에 Agile한 방식으로 4명의 멤버가 상호 소통하며 작업 아직 기획자/ 디자이너/ PMO/ QA/ SA 등 존재하지 않아 멤버마다 사고의 유연성이 필요
  • 72. 팀원 피드백 #2(주니어) • 이전 회사에서 인수인계 받은 코드에서 하나의 단어를 놓고 코드마다 다르게 사용해서 결과 값이 말도 안되게 나와 고생 • 단어에 대한 정의가 정확하다 보니 코드에서도 한눈에 알 수 있고, 어떤 것을 이해하지 못했는지 정확하게 파악할 수 있어서 질문자와 답변자 사이의 오해가 크게 줄어드는 효과가 발생 Ubiquitous Language • 문법 검사 정도에서 끝나지 않는 코드 리뷰 • 개발자 모두가 코드 리뷰에 참여 하기 때문에 리뷰 하는 사람들이 코드의 의미를 정확하게 알 수 있도록 코드 하나 하나 신경 써서 작성하게 되는 효과가 발생하는 것을 경험 중 코드 리뷰
  • 73. 팀원 피드백 #3-1(신입 나부랭이-명확한 프로세스) 유저 스토리 도출 -> 워크 아이템 등록/ 할당 -> 코딩 -> 코드리뷰 -> 병합 작업 프로세스가 명확하기 때문에 지금 하는 일이 끝나면 뭘 해야 하는 지 알고 있다 그래서 뭘 할지 잘 몰라 안절부절 하고 있을 일이 별로 없다
  • 74. 팀원 피드백 #3-2(신입 나부랭이-코드 리뷰) 읽는 사람을 배려하기 위해 들이는 노력이 스스로에게도, 코드의 품질에도 긍정적인 영향을 준다는 것을 느낌 CTO가 매의 눈이라 코드 사이에 낀 먼지도 볼 것 같아, 커밋 하나 하나에 훨씬 신중 별도 요청 사항(“API에 식빵도 넣어줘!” 같은…?)도 코드 리뷰로 확인하기 때문에 커뮤니케이션 미스로 인한 master 브랜치 오염을 차단하는 효과
  • 75. 팀원 피드백 #3-3 신입 나부랭이 통합 툴 사용 입사 전에는 Slack, GitHub, GitHub Project, Google Docs, Hangout를 사용 ‘스위칭 리소스’라는 고급진 표현이 쓰이는데, 이거 켰다 저거 켰다 하는 게 정말 귀찮았음 다른 도구로 넘어갈 때 마다 사고가 초기화 되어 뭘 하려고 했는지 한 번 더 생각함 지금은 VSTS 위에서 모든 것이 해결되기 때문에 너무 편하고 사고 정지 횟수 감소 이 약은 먹어봐야 앎
  • 76. 팀원 피드백 #3-4 신입 나부랭이-배포 자동화 “배포알못인 저도 클릭 두 번이면 배포가 가능합니다!”
  • 77. 페어 프로그래밍 팀 구성원 피드백 #3-5(신입 나부랭이)
  • 78. 고맙습니다! 오마이랩 기술팀 채용 문의: recruit@ohmylab.com

Notas do Editor

  1. 기능 테스팅은 기본적으로 빌드 및 배포 파이프라인에서 Azure 인프라에 배포 후 구동되는 코드를 대상으로 수행된다. 프로그래머는 빠른 피드백을 얻기 위해 작업 환경에서 기능 테스트 케이스를 실행한다. 로컬 기능 테스팅 시 응용프로그램 인스턴스는 Visual Studio와 IIS Express를 이용해 구동한다. 로컬 기능 테스팅 시 관계형 데이터베이스는 SQL Server Express를 이용해 구동한다. 로컬 기능 테스팅 시 저장소 계정은 Azure Storage Emulator를 이용한다. 로컬 기능 테스팅 시 Azure Event Hub는 작업 환경에서 대체될 수 없기 때문에 로컬 기능 테스팅을 위한 인스턴스를 이용한다.