Azure DevOps 커뮤니티 런칭 행사 다녀왔습니다. 비가 오고 날씨가 다시 추워졌는데 많이 오셨네요. 이제 집에 도착해서 정리하고 있습니다. ^^ 정말 발표하신 분들이 준비 엄청나게 하셨네요. 4시간이 어떻게 지났는지 모르겠습니다. 정말 수고하셨습니다. ㅎㅎ
강의 들으면서 요약한 내용들 올립니다. 다음주 4/3일, 4일에 있는 이그나잇도 기대됩니다. 요즘 조금씩 머신러닝, 클라우드에 대한 공부를 병행하고 있습니다. 앞으로의 미래 먹거리 중에 하나라고 생각합니다.
Azure DevOps Community Launch
예약은 350명정도 깃허브 인수로 에저 시너지를 내고 있다.
데브옵스 커뮤니티 런치 행사
183번째 Azure DevOps
김태영, 김명신, 이진석, 이종인님 발표
소개와 동향 그리고 기대효과
S&P500개의 회사가 2026년 변환된다.
월마트 1등 -> 불과 18년만에 세상이 얼마나 빨리 바뀌었는지를 알 수 있는 지표
2000년도 조사. 절반정도의 회사가 남았다. 20년만에 회사의 절반이 사라짐.
불과 8년 후가 되면 다시 절반이 대치가 될 것이다. 비디오대여업체가 넷플렉스로 대치가 됨
택시, 에어비엔비, 트윗, 페이스북 -> 미디어 유통을 담당하고 있다. 불과 몇년
새롭게 부각된 업체들의 장점은 특히 소프트웨어 개발이 주축을 이룬다. 경쟁력이 있으려면
소프트웨어 경쟁력이 있어야 한다.
움직이는 과녁 -> 뭘 공부해야 살아남는가? 개발자보다 회사의 경영하는 분들이 더 불안해 한다.
모호함의 세상 방향을 게속 바꿔야 한다. 비슷한 곳으로 쏘고 게속 수정하는 방법.
빨리빨리 Accelerate를 외치고 있다.
Fast Curve Ball 우리가 원하는 것은 빠르고 변화가 심한 것을 원한다.
기민하게 움직일 필요가 있다.
혁신 <-----> 신뢰 (소프트웨어 출시의 패러독스)
speed control
빨리 새로운 소프트웨어를 출시해야 한다.
소프트웨어의 출시가 느리다. 최종 사용자에게 도달하기 까지 6주 정도가 걸린다.
왜 느리죠?
한번에 너무 많은 일을 한다.
불필요한 새로운 아이디어를 많이 이야기 한다.
개발팀이 일을 끝내도록 내버려 두지 않는다.
감당할 수 없는 프로젝트였다.
팀원들을 개발이 아닌 다른 일을 시킨다.
결론을 보면
요구사항의 변화
개발, 운영의 전문성, 역량 결여
협업, 소통의 결여
자동화된 과정, 절차, 체계, 시스템의 결여
무엇을 개선할 것인가?
문화
과정/절차
도구
DEV + OPS -> 앞의 3가지를 말하고 있다.
plan, create, verify, deploy, release, configure, monitor를 한다.
DevSecOps, DevSecOpsBiz, Dev*Ops, ArchOps... 결국은 소프트웨어 전반에 걸친 모든 과정을 다하자.
DevOps를 잘 적용한 사례를 보니
배포주기가 46배 빨라짐. 개선 속도가 440배 빨라짐. 변경실패율이 1/5로 줄어듬. 복구 시간이 96배 빨라짐.
시장 진입 속도가 20% 개선됨. 매출도 20% 정도 신장된다.
DevOps는 그냥 협업, 자동화, 인프라스트럭쳐엔코드. 스위치이다. 틀린 이야기이다.
DevOps를 하면 콜버레이션을 할 수 있다. 다 할 수 있다. AWS도 철학, 빠른 속도로 빠르게 개발하고 배포하는 것이다.
위키도 비슷한 이야기를 한다. 프렉티스셋, 변화를 말한다. 다양한 곳의 내용을 뽑아서 공통 부분을 이해.
버즈워드를 이해할 경우
"데브옵스는 사람, 프로세스, 제품의 합체이다. 엔드유저에게 가치를 끊임없이 제공하는"
플래닝
빌드와 테스트
배포
모니터링과 운영
DevOps화
DevOps적 문화
DevOps적 도구를 도입하는 것
Trust, Share, and Collaborate 를 하는 것을 말한다.
Developers + Operators
토대 구축
모니터링, 로깅, 알림을 구성할 수 있도록 구축
재사용 가능한 패턴 구축
실용적 단계
기본적인 자질과 문화. 퍼멧이 발표한 자료
State1: 소스 컨트롤을 도입해야 한다.
State2: 운영체제를 어떻게 표준화할 것인가? 표준화된 세트가 필요하다.
State3: 표준화된 기술세트를 사용한다.
State4:
State5:
MS도 DevOps를 한다.
지속적인 통합(CI)
Azure DevOps를 사용한다. 5가지 세트로 구성되어 있다.
Azure Boards
Azure Pipelines
Azure Repos 리파지토리를 활용하고 끌어오기 요청
Azure Test Plans
Azure Artifacts 소프트웨으를 패키징할 때 사용한다.
비주얼소스세이프 -> 팀슈트 -> DevOps로 계속 기술이 변경됨.
얼마나 오래동안 시장에서 살아남는지가 중요하다. Leaders그룹에 MS가 포지셔닝되었다.
하루에 배포의 수가 86000개 정도 된다. 일초에 한번씩 소프트웨어를 배포하고 있다. 96000명의 직원이
내부에서 사용하고 있다.
캡쳐를 해서 올린 데모. 깃허브와 유사한 환경을 제공해 준다.
빌드 파이프라인, 릴리즈 파이프라인을 만든다.
Azure DevOps Service는 월에 33,000원정도 이다. 5명의 소규모 팀은 무료
오픈소스 프로젝트도 무료. 일인당 6000원정도면 사용할 수 있다.
보안때문에 사용할 수 없다면 Azure DevOps Server를 사용하면 된다. TFS서버를 사용하는 것과
비슷한다.
https://dev.azure.com
Azure DevOps,
CI/CD를 위한 5개의 핵심기능 살펴보기
지속적인 통합(CI)
지속적인 딜리버리(CD)
CI/CD를 통한 지속적인 배포
-> 가장 먼저 쉽게 시도해 볼 수 있는 2가지 사람, 프로세스 및 도구를 활용하는 것이다.
소소한 기능의 일부를 한번 CI, CD에 태워보는 것이다. 약간 부가적인 프로젝트에서 POC성격으로
해보는 것이다.
Continuous Integration
코드의 개발 및 테스트를 단순화
개발 초기에 버그나 문제를 파악하는데 도움
자동화된 테스트와 빌드
산출물로는 빌드 아티팩트가 생성된다. 이를 자동화하면 CI가 된다.
Continuous Delivery
하나 이상의 테스트 및 운영 환경
배포하는 프로세스 품질 향상을 할 수 있다.
자동화된 릴리즈 파이프라인은 기존 시스템에 새로운 버전과 수정 사항을 릴리즈한다.
왜 두개의 파이프라인으로 나누는가?
Build 파이프라인 -> 빌드, 단위 테스트 (이렇게 해야 선택지를 분리할 수 있다.)
Release 파이프라인 -> 배포 환경 프로비저닝, 승인, UI테스트, QA테스트, 통합테스트, 배포
DevOps는 최종 사용자에게 가치를 지속적으로 전달하기 위해 필요한 프로세스, 도구, 사람의
결합이다.
비주얼소스세이프 -> ALM -> DevOps
DevOps는 필요하면 외부 도구를 연계해서 사용해도 된다. 깃허브, 젠킨스...
AWS로 배포해도 된다. 팀 내부의 너무 많은 협업 도구를 익히는데 시간이 걸린다.
한번 쓰기 시작하면 살살 넘어오게 된다.
Azure Boards -> 옛날에는 엑셀로 사용했다. 팀간의 작업을 계획, 추적을 논의
Azure Pipelines
Azure Repos 리파지토리를 활용하고 끌어오기 요청
Azure Test Plans -> 테스트, 로드 테스트를 할 수 있다.
Azure Artifacts -> 팀내의 리파지토리를 제약을 걸고 공유할 수 있다. 정해진 버전만 인스톨할 수 있다.
좋아하는 클라우드와 도구를 선택한다. 편집기 운영체제, 클라우드를 선택한다.
AWS로도, 쿠버네티스로도 배포할 수 있다.
Azure Pipelines
클라우드에서 호스팅되는 파이프라인, Linux, Windows, macOS지원, 오픈소스의 경우 시간제약 없이 지원
macOS도 지원한다. 빌드를 하고 vm이 사라진다.
Azure Boards
Kanban보드, 백로그, 팀 대시보드
Azure Repo
무제한 private Git Repo
Azure Test Plans
전체적인 추적성 확보, 브라우저에서 테스트를 실행하고 결합을 찾는다.
Azure Artifacts
누겟, 파이썬 패키지 모두 가능
확장 기능
700개 이상의 Azure DevOps및 TFS 용 확장 기능
대중적인 상용 가능
ContentAPI
ContentAPI.tests
(모킹기반의 단위 테스트)
ARM(Azure Resource Manager)템플릿
azure web app template을 치면 나온다. 깃헙에 샘플이 엄청 많다.
새로운 코드를 셋팅하면 자동으로 작업됨. UI/부하 테스트가 끝나고 승인을 하면 넘어간다.
두번째 데모는 젠킨스, 테라폼을 사용한 데모
4개의 프로젝트로 구성되어 있음. 태오닷넷의 모바일 버전을 실제 만들었다.
WebAPI-CI빌드를 데모
소스를 다양한 저장소에서 가져올 수 있다.
Hosted에서 빌드 머신을 선택할 수 있다. 기본 옵션으로 우분트를 많이 사용한다.
빌드 vm, 내부 서버와 연계도 가능하다. TaeoyLocal을 선택할 수 있다. 다운로드 에이전트를 설치하면
된다. 스크립트를 설치하면 Online으로 상태가 바뀐다.
.NET Core를 사용해서 Web API를 개발 배포...
파일 결과를 폴더에 Publish한다. 집에서 핸즈온랩을 따라해 본다.
Hosted Ubuntu 1604에는 닷넷 코어가 있지만 없다면 스텝으로 추가해야 한다.
마켓플레이스에 대부분의 써드파티들이 있다.
빌드하고 푸쉬하면 바로 진행된다.
빌드에 트리거가 있다. Enable Continuous Integration을 체크하면 된다.
E2E가 끝나면 한번 승인을 받아서 배포를 하도록 셋팅했다.
젠킨스 서버에 이미 빌드가 되어 있는 것을 볼 수 있다.
target/*.war 파일을 만든다.
Variables에 환경변수처럼 저장할 수 있다.
메일로 온 승인을 누르면 바로 배포됨.
에저 데브 리포에서 젠킨스로 던지고 빌드가 되면 다시 진행
dll과 war파일이 별도로 생성된 것을 볼 수 있다. Artifacts를 보면 된다.
Export를 미리 해둘 수 있다. 또는 send email을 사용할 수 있다.
파이브라인에 Export를 눌러서 json으로 만들어준다. Import해서 새로 만들면 그대로 복구된다.
테스트 케이스를 준비해두면 자동으로 테스트가 된다. 기존 비주얼스튜디오에서 하던 기능이 그대로 웹으로
구현된 느낌이다.
문제가 생기면 캡쳐를 할 수 있다.
마켓플레이스에 Extensions for Azure DevOps가 있다. 브라우저에 애드온을 설치할 수 있다.
크롬, 파이어폭스를 지원한다. 엣지는 지원하지 않는다.
그러면 모든 테스트가 녹화가 된다.
Create Bug를 선택하면 모든 버그가 녹화가 된 것이 그대로 나온다!!! 신기
테스트 케이스로 등록해도 된다.
부하 테스트에 URL을 저장하고 어느 지역에서 부하를 걸지를 지정할 수 있다. 대신 꽁짜는 아니다.
만명 정도 테스트하려면 부하 테스트 장비 수십대가 필요한데 저렴하게 사용할 수 있다.
퍼블릭 누겟을 우리쪽에서 사용할 수 있다. 미리 받는 용도 또는 이전 버전을 사용할 경우 우리 팀 피드에서
받아라는 버전 관리 용도로 사용할 수 있다.
브랜드가 아니다. 노메서드이다!!!
다양한 피처들을 이용하면 테스트와 빌드를 인스턴스 없이 사용할 수 있다.
이진석 대표
로컬에서 엘라스틱 Beanstalk로 배포
Azure Pipeline으로 배포
awsebcli를 활용
릴리즈를 스테이징과 프로덕션을 구별함 vm이 2개가 생성된다.
GitHub저장소와 Azure Pipelines 연동
pypa/pipenv
python/cpython
pandas-dev/pandas
CPython저장소 - 3.8 에저 활용하고 있다.
기본 지원되는 다양한 Hosted Agent
ubuntu-16.04
windows-2019
vs2017-win2016
방법1)GitHub Marketplace를 통한 연동
방법2)Azure DevOps프로젝트 내에서
프로젝트 이름 지정하고 public으로 생성
하단의 클래식 에디터를 클릭한다. YAML을 클릭하면 안된다.
그러면 시각적 편집기가 제공도니다. 깃헙에서 가져오고 인증을 수행한다.
저장소를 클릭하고 master로 한다. 빌드 스테이지를 만든다.
CI와 빌드 저장소가 연결된다.
빌드 생성
참고)환경변수로 알아본 빌드 Agent디렉토리 내역
Agent작업에서 use python version이 나온다.
16.04는 2016년 4월에 출시된 우분트 버전을 의미한다. 이미 파이썬 3.7이 설치되어 있다.
파이썬 패키지를 설치해야 한다.
bash를 설치한다. 필요한 패키지를 인라인으로 입력한다.
pip install -r requirements.txt
pip3이라고 써도 된다.
테스트 수행
python manage.py test
jnit포맷으로도 출력이 된다.
Publish test result로 검색한다.
기본으로 있는 내용들을 그대로 둔다.
git archive --format=zip 으로 압축을 한다.
아티팩트로 보낼 파일들을 생성한다.
Artifact로 발행
프로젝트내에 스태틱 파일들을 수정한다.
save & queue를 누르면 빌드가 자동으로 된다. save를 누른다.
TEST가 실패했을 때, TEST-*.xml파일 내역 샘플
빌드 Stabus Badge기능이 있다.
URL과 Markdown이 있다. readme.md 파일 같은.
git commit
git push
빌드에서의 다양한 트리거 옵션
슬랙의 Azure Pipelins앱도 있다.
슬랙도 연동됨. 약 4~5초 정도 걸린다.
빌드 노티도 받을 수 있음
발드 완료 알림이 슬랙으로 간다.
archive/archive.zip으로 저장된다.
빌드번호가 1씩 증가한다.
릴리즈에 필요한 세팅들
AWS Tools for Microsoft Visual Studio Team Services 설치
AWS Shell Script / CLI
AWS S3 Upload
AWS Elastic Beanstalk
AWS Scret / Access Key가 필요하다.
/home/vsts/work/r1/a에 파일들이 자동으로 다운로드된다.
릴리즈를 클릭해서 추가한다. 빌드에서 결과를 가져온다고 클릭한다.
최신버전을 지정하고 Source에서 이름을 drop으로 한다.
스테징단계에 테스트를 추가할 수 있다.
엘라스틱은 파이썬 버전을 3.6으로 한다.
Create Elastic Beanstalk
Deploy Elastic Beanstalk
eb status
eb create
환경을 만들어준다.
eb setenv
시각적 편집기가 직관적으로 제공된다.
클론을 누르면 복제가 된다.
오른쪽의 번개 표시를 누르고 CD를 진행한다.
해당 유저에게 승인을 받도록 한다.
git ci/cd push
clear
한달을 공부해서 발표함.
(느낌이 비지톡에 있던 파이프라인이 들어온 느낌이다.)
--force를 주면 물어보지 않는다.
오늘부터 당장 DevOps를 시작하자!
.NET - Unified Platform
하지만 크로스 플랫폼
이 많은 플랫폼에 대한 빌드 및 배포를 직접?
어떻게 하면 잘 할 수 있을까에 대한 고민
Nuget패키지를 업데이트 했는데 어느 프로제트에서 호환이 안된다면
특정 로직이 특정 플랫폼에서 의도치 않게 돌아가는 일은 없을까?
일부 프로젝트에 빌드가 깨져 있었다면?
앱 및 서비스가 각각의 플랫폼에서 잘 돌아가는지에 대한 확인은?
20개가 넘는 프로젝트와 테스트를 관리하기 위해서 사용
코드를 올리면 수 많은 플랫폼에 빌드, 테스트 배포
Azure Web App, Functions, Windows, iOS, Android등 지원하고자 하는 모든 플랫폼 빌드 배포
서버와 클라이언트까지 배포되어 새로운 로직을 모든 곳에서 테스트
서비스와 앱이 모두 같이 업데이트가 되길 바란다.
Visual Studio App Center
빌드된 ios, Android, win 앱들을 App Center로 자동으로 보내 각 플랫폼에 배포
수많은 종류의 디바이스에서 UI테스트등 사용 테스트를 할 수 있음
빌드 혹은 테스트 실패로 걸러지는 많은 오류
빌드가 깨지면 다시 원인을 발견해서 던져넣으면 된다.
타겟 플랫폼에 거의 동시에 배포되는 새로 만들어진 로직
주요 과정들을 간략하게 데모
브랜치 생성하고 주석 추가 커밋
create pull request 를 클릭한다.
파이프라인을 이틀정도만 만들고 개발에 집중할 수 있다.
Azure DevOps로 개발 운영
새로운 팀원이 합류하자 마자 겪었던
코드 베이스로 병합되지 않는 새로운 팀원의 Pull Request
테스트 실패
기반 라이브러리, 여러 로직에 걸쳐 짜여져 있는 경우
서로의 코드를 파악하지 못함. 버그를 한참 뒤에 알게된 경우라면
브랜치 정책
팀에서는 develop, master브랜치에 브랜치 정책 설정
해당 브랜치는 빌드 정책 설정으로 빌드, 테스트 통과
빠른 문제 파악
개발자는 빌드, 테스트가 모두 통과된 브랜치에서 새로운 브랜치를 생성해 작업
코드 리뷰
빌드 성공은 컴파일은 된다는 최소한의 보장이며 테스트 역시 모든 로직을 검증하는데는 한계가 있다.
코드 리뷰를 통해 체크
Azure Board와 Pipeline은 단순히 탭으로 별도로 나눠진 기능이 아니라 서로 통합 및 연계되어 있음
한바탕 코딩 후 찾아오는 설명의 시간
Work Items를 추가한다.
웹 기반으로 개발자간에 협업이 쉽게 되어 있다.
커스텀하게 워크 아이템 항목들을 만들 수 있다.
App Center Team에서 메일이 온다. 메일을 오픈해서 인스톨을 한다.
인 앱 업데이트를 코드에서 설정할 수 있다.
결국에는 운영
진행상황에 대한 지속적인 피드백
객관적이긴 어렵지만 객관화 되어야 하는 지표
프로세스의 문제가 감지되면 계속해서 개선해나가야 함
Azure DevOps는 결국에는 운영 도구
작업 내용과 통과 조건 등을 잘 담고 있어야 하는 Work Item
코드 퀄리티를 보장하는 실효성 있는 테스트 개선
진행상황의 지속적인 평가, 피드백 수집, 개선
