올해부터 꾸준히 자격증 시험도 보고 Azure 클라우드 교육을 받고 있습니다. 교육을 하는 것이 아닌 받는 것도 무척 재미있습니다. 20대와 30대 개발자, 엔지니어분들과 같이 교육을 받는 것도 좋으네요.
구내 식당 모습입니다. 5천원에서 7천원정도 합니다.
강북에 있어서 자주는 못오지만 노트북을 들고다니면서 도서관에서 작업하는 것보다 여기 창업 허브가 더 환경이 쾌적합니다. 노트북 작업 공간이 상당히 많고 도서관도 있고 구내 식당도 있습니다.
이틀간 무료로 교육이 진행되는데 점심도 제공됩니다. 두번째 방문인데 항상 식사는 만족스럽습니다. ㅋㅋ
수업 들었던 내용들 정리한 것 올립니다.
깃허브는 작업관리가 명쾌하지 않다.
DevOps는 작업관리가 명쾌하다.
VS Pro와 Community는 동일하다.
깃허브 인수와 자마린 인수가 신의 한수다.
DevOps Infra
Azure DevOps(구 Team Foundation Server)
Azure DevOps Server ==> 온프라미스 버전이다.
GitHub
App Center(Mobile DevOps)
자마린은 플랫폼당 2천불정도 였다. 모바일 데브옵스가 따로 있다.
앱 센터가 붙는다. 자마린은 개발도구라기 보다는 플랫폼에 가깝다. 하키앱
모바일은 배포와 테스트가 심하다. 모바일은 파편화가 심해서 6천개 정도를 테스트 해야 한다.
이제 자마린을 통해 맥도 비집고 들어왔다.
DevOps가 아카데믹한 이름으로 브랜딩이 되었는데 제품명으로 사용되니 혼란스럽다. 아키텍쳐로 오해하는 사람들이 많다.
.NET Core SDK 설치해야 한다.
filezillar를 설치한다. 파일을 복사할 때는 편한다.
(mac, window... )
postman을 설치한다. 웹개발에서는 거의 필수로 사용한다.
https://www.getpostman.com
WCF도 거의 웹으로 흘러간다. 호스팅을 웹으로 한다. 배치도 에저웹으로 한다. 모든지 웹으로 흘러간다.
마이크로 서비스의 기본 채널이 웹이다. REST기반으로 한다.
git-scm download 설치하기
azure cli 설치하기 ==> 요즘은 에저 모듈이 주력이다. 파워쉘이 지고 에저 모듈이 승리하고 있다.
azure cli로 되어 있는 샘플이 늘어나고 있다.
프리패스의 경우 2개월 정도 지나면 에저 패스가 다시 등록 가능하다.
스터디 3총사
docs
www.youtube.com/user/microsoftlearning 한글자막으로 자동 번역할 수 있다.
샘플소스는 github에 있다. 깃허브에 모든 샘플 코드가 다 모이고 있다.
400의 랩이 정말 잘되어 있다.
https://azuredevopslabs.com/
103, 203을 하고 400을 공부하면 된다. 3가지 정도면 커버한다. 에저의 80~90프로를 커버한다.
원래는 5일정도인데 2일정도로 진행한다.
첫번째 모듈에 집중한다.
Azure DevOps 소개
DevOps는 사용자들에게 지속적으로 가치를 전달하기 위한 사람, 프로세스, 도구의 집합체
애플리케이션 수명주기의 관점에서 개발과 관련된 부분을 다른다.
워터폴과 에자일을 결합한 관점으로 진행 1년이면 요구사항 정리, 설계, 개발과 안정화
그런데 공정에 맞지 않는다. 건설과 다르게 it는 좀 다르다. 기술이던 요구사항이던 변경될 수 있다.
일년 작업을 좀 더 나누어서 한다. 통합과 반복, 통합과 반복 어자일의 핵심이다.
개발자가 만드는 코드의 작업을 지속적으로 한다. 계속 프로세스를 반복한다.
그동안 늘 해왔던 작업이다. 좀 더 아카데믹하게 프로세스에 맞게 해보자. 구현할 수 있는 도구를 사용하자.
LMS 툴과 비슷하다. ALM라고 많이 이야기해 왔다. 좀 더 DevOps는 경량화 된 느낌이 있다.
개발자 IT관리자 현업간에 괴리감이 있다. 한번 만들어진 앱이 40%가 재작업이 이루어 진다.
200분 정도 소요시간이 걸린다. 커뮤니케이션의 부재에 있다. 어자일 방법론이 그래서 도입되어 있다.
거의 대부분이 어자일을 사용한다. 90%이상이 사용한다. 깃허브... 어자일 아니면 좀 더 가벼운 스크럼
Agile mothodolgogies
어자일이 좀 더 높은 성공률을 보이고 있다. 40%정도의 성공률을 보인다.
Application Lifecycle Management System
JIRA git docker ...
maven splunk datadog
오픈소스를 짜집기하는 느낌이 난다.
아직도 svm을 많이 사용한다.
azure devops에는 대부분 포함되어 있다. 최근 보안회사에서 자바기반의 데브옵스를 하고 있다.
오픈소스로 짜집기하는 작업이 너무 많다. 2주를 넘지 않는데 3주째 작업을 하고 있다.
그래서 엔지니어의 레벨이 높고 비싸다. 데브옵스 엔지니어가 수요가 많다.
도구 이전의 문화
SW개발 절차에 대한 이야기
개발과 운영을 한방에 (103, 203을 같이 듣고 있다)
SW개발자에게 독박을 ==> SE엔지니어에게 위기 상황일 수 있다.
같은 일을 반복하지 않고 자동화
소통이 최상의 방법론 ==> 가장 중요한 것은 소통이다. 시스템과 시스템, 사람과 사람, 시스템과 사람
클라우드로 넘어가면서 SM작업이 비중이 확 줄어들었다. 소프트웨어 엔지니어에다가 좀 더 역할을 하게 된다. 시스템 엔지니어의 역할은 좀 더 낮아지고 있다. 코드로 인프라가 전환되는 현상이 뚜렸하다. 테라폼이나 야물 템플릿을 많이 사용하고 있다. 깃허브에서 인프라도 관리되고 있다.
시장 진입 속도가 20% 개선됨
매출은 20% 개선됨
이것을 구현하려면 풀스택 엔지니어가 필요하다.
에저 데브옵스는 일관된 화면과 인터페이스로 공유할 수 있다는 장점이 있다.
기획자가 코드나 테스트 결과를 보고 싶을 수 있다.
내가 요구한 작업이 어떤 코드로 만들어졌는지 볼 수 있다.
Azure DevOps
(구 Team Service)
Azure DevOps Server
(구 Team Foundation Server)
==> 한글이 인식된다는 장점이 있다. 온프라미스 서버의 경우 한글이 지원된다.
제품군이 5개 정도 지원된다.
WBS가 Azure Boards이다. 그 안에 설계를 녹일 수 있는 공간이다.
Azure Repos는 코드가 저장된다.
Azure Pipelines를 통해서 배포한다. 쟁킨스, 메이븐...
Azure Test Plans 를 통해 테스트 관리. 주기가 짦고 빨라져서 TDD가 더욱 필요하다.
Azure Artifacts 패키지를 생성. CI/CD에서 핵심을 아티팩트이다. 2주마다 배포를 한다고 보면 라이브러리로 말아서 사용한다. 누겟이나 npm채널이 바로 Azure Artifacts채널이다.
오픈소스는 각각이 브랜딩이 되어 있다. 지라... 그런면에서 MS가 약해보인다.
Agile스프린트 한 개 만들기(그리고 뺑뺑이)
-하나의 주기, 한개의 프로젝트, 한덩어리의 작업
빨간박스를 하나 한땀한땀 만들면 나머지는 자동
작업내역 -> 개발 -> 코드 저장소 -> 빌드 -> 테스트 -> 배포(staging) -> 배포(Production) -> 피드백
Azure Board -> Visual Studio -> Azure Repo -> Build agent -> Azure Pipeline -> Azure Pipeline -> Feedback
(이름이 약해 보인다. ㅎㅎ 젠킨스에 비해서 Azure Board ㅋㅋ )
테란 팀장
파이프라인 키워드
PM, PL
작업요청, WBS, 요구사항
테스트 구성, 확인
Staging확인
Production배포 승인
WBS vs WorkItem구조 비교 - 팀장님에게 꼭 알려주고 싶은 이야기
계층작업을 보여주는 작업을 노다가로 했다.
모든 업무는 3단계로 정의해야 한다고 생각한다.
피처 유저스토리 태스크 Description 담당자 Iteration
1Depth 2Depth 3Depth Description 개발담당 일정 일정. etc
(네임스페이스) (클래스) (데이터베이스) (메서드가 된다.)
저그 개발자
파이프라인 키워드
흔한 개발자
작업 리스트
개발코드 저장소
CI/CD
빌드에이전트
테스트
배포채널
Azure kubenets Services
처음에 개발자가 다 해주면 자동화 된다.
코드저장소는 Git이나 TFVC를 모두 쓸 수 있다.
서버기반이건 분산파일시스템이건 사용할 수 있다.
깃은 분산기반 TFVC는 서버기반이다. 개인 경험상 2~3년정도 밖에 안된다. 서버 기반에서 분산기반으로 넘어온 것
지금은 코드저장소가 기본이다.
같이 사용하는 것도 가능하다. 2개 또는 3개를 사용할 수 있다.
저장소는 백만개를 만들어도 된다.
워크아이템 별로 하나의 Branch를 따서 작업하면 정신건강에 도움 된다.
코드리파지토리이지만 도큐먼트와 소스를 같이 운영한다.
엑스박스팀은 없어짐. 리미트 없이 많이 담을 수 있다.
브랜치의 기본을 로컬이 둘지 원격에 둘지 결정해야 한다.
개인적으로 태스크별로 브랜치를 따는 경우는 거의 없다.
개발브랜치, 마스터브랜치, 스태이징브랜치로 만든다.
테스트는 귀찮아 보이지만 해보면 더 귀찮아요. 그래도 만들어두면 정신건강에 도움되요.
바쁠수록 만들어야 한다.
DB를 저장소로만 쓰려고 한다. 비즈니스 로직을 어디에 둘것인지?
프론트 엔드 + 미들웨어 + 저장소
해당 도메인을 구성하는 곳에 DB개발자가 많으면 DB에 두는 것이 유리하다.
대부분 앱 엔지니어가 많다면 미들웨어이 둔다. 병원의 경우 DB개발자가 많다. SP하나가 만줄이 넘는 경우가 많다.
DB에 로직이 많으면 TDD를 하기가 어렵다. 미들웨어에 있다면 TDD가 유리하다.
프로토스 현업담당자
파이브라인 키워드
독사같은 현업 담당자
서비스패키지검토,
표준화하고 프로세스화하고 싶다는 것을 자동화 한다.
모두가 컨테이너를 담을 수 있는 상자이다. 모두 컨테이너로 말고 있는 느낌이다. 클라우드베이스로 하면 컨테이너로 말고 있는 경우가 많다. 고가용성, 고성능을 보장해 준다.
스테이징 상태에서 전부 확인하고 승인하면 프로덕션으로 배포된다.
블루그린 스테이지(2개가 동일한 환경으로 운영된다. 장애가 나면 바로 전단계 상태로 복원한다. 이것이 블루그린 전략)
에저 파스는 쉽게 이 전략을 제공한다. 이것을 모두 자동화 한다.
Azure DevOps는 공짜(5인 이하, 10억이하)
워크아이템은 팀에서 사용중인 레거시와 연동, 커스터마이징 가능
개발코드는 굳이 Azure DevOps의 Git Repository를 사용하지 않아도 된다.
Azure Kubernets Service는 한번만 써본 사람이 없다.
실생실사 백문이 불여일런
- 기획 + 요구사항추적
- 개발 + 테스트
- 빌드 / 배포 CI/CD Pipeline
- 모니터링 + 피드백 Application Insight Feedback client
개발 + 운영을 하나의 빨간 박스를 처음부터 끝까지 해본다.
아주 간단한 프로젝트를 처음부터 만들어 본다.
Broodwar라는 프로젝트를 만든다.
웹프로젝트는 Starcraft로 정한다.
관리자는 Zerg개발자에게 웹프로젝트 작업 배정
기획/요구 PM/PL
개발 Developer
테스트 Tester
빌드/배포 Operator
피드백 User
dev.azure.com에 가서 로그인한다.
Broodwar로 생성한다.
Boards에 들어가서 워크 아이템을 피처로 만든다.
엑셀의 팀 메뉴에서 새 목록을 클릭한다.
추가해서 dev.azure.com/papa... 을 입력한다.
오피스 2013부터 팀 메뉴가 나온다. 맥에서도 안나온다. 2019버전에서 확인해 볼 것
자유도가 높은 WBS이다.
MS Project와는 잘 맞지 않는다.
비주얼스튜디오, 이클립스와도 같이 연동된다.
개발 + 테스트
코드 작성 -> 단위테스트 -> 소스제어 -> 빌드 -> 빌드확인 -> 배포
Zerg개발자가 ASP.NET NVC 웹프로젝트를 생성
배정받은 라벨변경 작업을 수행
git status
git add .
git commit -m "" ==> 워크아이디를 지정해야 한다.
도구에서 마우스 오른쪽 버튼 커밋을 클릭한다.
라벨변경
원만하면 깃은 커맨드를 사용해서 처리한다.
vs Enterprise에 추가 템플릿을 VS Installer를 사용해서 설치했다.