Microsoft Azure DevOps

목차:

• 요약
  • 이슈
  • 결정
  • 상태
• 세부 사항
  • 가정
  • 제약
  • 입장
  • 논거
  • 영향
• 관련 항목
  • 관련 결정
  • 관련 요구사항
  • 관련 산출물
  • 관련 원칙
• 메모
  • Microsoft Devops CI: 만족스럽지 못한 모험
  • Hacker News 토론 하이라이트
  • Windows 개발 MVP
  • Edward Thomson(Azure PM) 요약

요약

이슈

우리는 프로젝트를 빌드, 통합, 배포, 호스팅하기 위해 데브옵스를 사용하고자 합니다. Microsoft Azure DevOps를 검토하고 있습니다.

• 데브옵스의 설정(예: 구성)과 지속적인 사용(예: 빠른 빌드 시간) 모두에서 개발자 경험이 빠르고 신뢰할 수 있기를 원합니다.

• 프로젝트 앱, 데이터베이스 등을 호스팅하기 위해 Microsoft Azure 전체를 사용하는 것을 고려하고자 합니다.

결정

Microsoft Azure DevOps를 선택하지 않기로 결정했습니다.

상태

결정됨. 새로운 중요한 정보가 들어오면 다시 검토할 수 있습니다.

세부 사항

가정

Accelerate 책에 나오는 것 같은 모든 일반적인 데브옵스 가정.

• 빠른 빌드는 상당한 도움이 됩니다. 이는 피드백 루프를 가속합니다.

• 대체 벤더의 조각을 교체해 넣거나 뺄 수 있습니다. 즉 더 빠른 자체 빌드 서버를 가져오거나, 버전 관리 시스템을 직접 선택하거나, 자체 호스팅 지속적 통합 서버와 조율하고자 할 수 있습니다.

• 간소화된 사용성은 개발자 경험에, 그리고 이어서 일관성, 명확성, 보안, 학습 곡선의 용이성 같은 미묘한 영역에 상당한 도움이 됩니다.

• 무언가가 고장 나거나 문제가 있을 때 이슈를 보고할 효과적인 방법을 원합니다. 이는 보안 관련 이슈에서 특히 중요합니다.

제약

알려진 것은 없습니다. Azure는 외부 도구와 잘 어울리겠다는 공개적인 약속을 하고 있습니다.

입장

우리는 Microsoft Azure Devops 사용과 기존에 사용 중인 AWS를 비교하여 검토했습니다.

우리는 Azure DevOps, Azure Pipelines, Azure Repo, 그리고 Terraform을 통한 새 서버의 Azure 가동을 실험했습니다.

우리는 Microsoft 담당자로부터 지원을 받는 것을 실험했습니다.

우리는 블로그와 Hacker News에서 동료들의 정보를 수집했습니다.

논거

Azure DevOps는 훌륭한 제공물 집합을 내세우지만 그것들은 기대에 미치지 못하고, 서로 잘 작동하지 않으며, 지원도 부실합니다.

우리의 직접 경험:

• Azure 설정은 UI의 난장판이며, 그중 일부는 Microsoft 계정과 겹치고 일부는 겹치지 않습니다. 예를 들어 Azure 로그인, Microsoft.com 로그인, Live.com 로그인 등이 있으며 모두 동시에 관여합니다.

• 설정 중에 사소한 보안 이슈를 만났지만 해결책을 찾지 못했습니다. 많은 Microsoft 담당자에게 여러 방법으로 보고하려 했지만 성공하지 못했습니다. Microsoft 보안팀에는 성공적으로 보고했으나, 수정하지 않겠다는 답변이 돌아왔습니다.

• 문서는 종종 틀렸거나 오래되었습니다. 이는 적어도 일부는 Microsoft의 부실한 검색 엔진 때문이고, 일부는 평균 이하의 SEO 때문입니다.

• Terraform 설정은 문서화가 잘 되어 있고 작동합니다. 그러나 Microsoft가 벤더와의 비즈니스 관계를 구축하여 Terraform 연계 설정 예제를 만들게 하고 있기 때문에, AWS에 비해 Terraform 지원이 약합니다.

동료들의 경험:

• 우리 자체의 블라인드 평가를 마친 후 동료들의 경험을 찾아보았습니다. 우리가 찾은 것은 우리의 경험을 확인해 주었습니다.

• 동료들은 빌드 시간에 대한 추가 문제와 자체 빌드 서버 가져오기에 대한 문제를 보고했습니다. 이러한 문제는 UI 문제보다 훨씬 심각한데, 빌드를 수행하는 것이 빌드 파이프라인의 핵심 목적이고 우리는 하루에 많은 빌드를 수행할 것으로 예상하기 때문입니다.

• 우리는 토론 영역에서 Azure 팀원들의 훌륭한 참여를 확인했습니다. 이에 대해 Microsoft에 박수를 보냅니다. 특히 Azure PM이자 개발자인 Edward Thomson의 참여, 솔직함, 기술적 설명에 깊은 인상을 받았습니다.

영향

Microsoft Azure DevOps를 선택하면 Azure를 선택하지 않는 것보다 시간과 비용이 더 많이(약 3배) 들 가능성이 높아 보입니다.

관련 항목

관련 결정

Azure DevOps를 선택하면 Azure Repo, Azure Pipeline 등 많은 관련 제공물이 있습니다. 우리는 Azure Devops를 선택하면 더 많은 Azure 기능을 사용하기가 쉬워질 수도 있고, 다른 벤더의 기능을 사용하기가 어려워질 수도 있다고 믿습니다.

우리는 Microsoft가 개발자 경험에서 큰 진전을 이루고 있으며, 개발자 도구(예: GitHub)와 의존성(예: Citus)을 대규모로 인수하는 것을 보고 있다고 믿습니다.

Azure DevOps를 선택하면 Microsoft 인수 제공물을 선택하는 것을 강조하고 싶을 수 있으며, 직원 이탈 위험 같은 잠재적 조직 거부 반응 때문에 인수 제공물에 더 주의를 기울이고 더 많이 평가하고자 할 수도 있습니다.

관련 요구사항

우리는 빌드 시간이 매우 빠르기를 원합니다. 이를 위해 높은 프리미엄을 지불하는 것을 받아들입니다. 매우 빠르게 반복하고자 하기 때문입니다.

우리는 신뢰성이 매우 높기를 원합니다. 이를 위해 높은 프리미엄을 지불하는 것을 받아들입니다. 금융 거래, 기밀 거래 등을 포함한 고가치 사용 사례를 테스트하고 있기 때문입니다.

우리의 상위 4개 데브옵스 KPI에는 평균 복구 시간이 포함되며, 이는 빠른 빌드와 높은 신뢰성을 필요로 합니다.

관련 산출물

우리는 빌드 시스템이 Artifactory 같은 다른 시스템에서 사용하기에 적합한 산출물을 출력하기를 원합니다.

관련 원칙

쉽게 되돌릴 수 있음. 기존에 사용 중인 AWS와 병행하여 Azure DevOps를 평가할 수 있습니다.

메모

Microsoft Devops CI: 만족스럽지 못한 모험

https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/

블로그 게시물.

“소프트웨어 개발자로서, 저는 품질 좋은 제품을 빠르고 저렴하게 만드는 것이 얼마나 어려운지 직접 알고 있습니다. 그것은 우리가 때로는 제대로 해내고, 때로는 오바마 시절의 정부 의료보험 사이트 같은 것으로 전락하는 예술 형식입니다. 결과물에 대한 우리의 통제 수준은 다양하며, 실패에 대한 비난은 종종 의사결정 계층의 엉뚱한 사람들에게 돌아갑니다. Microsoft의 Azure DevOps(예전 이름은 Visual Studio Team Services)는 분명히 좋은 의도에도 불구하고 나쁜 결정과 부실한 실행이 만나 완벽한 폭풍을 이룬 것입니다.”

Hacker News 토론 하이라이트

https://news.ycombinator.com/item?id=18983586

“우리 회사에서는 Azure DevOps를 광범위하게 사용하는데, GitHub, Gitlab, 자체 호스팅 솔루션, Jenkins, TeamCity를 써 본 후에 보면... Azure DevOps는 완전히 꼴찌입니다.”

“UI는 어디서나 끔찍하게 투박합니다. 저에게 최악은 풀 리퀘스트입니다. 풀 리퀘스트에서 사람들과 작업하기가 믿을 수 없을 만큼 힘듭니다. 특정한 ‘하나의’ 문제를 짚을 수조차 없습니다. 우리에게는 모든 곳이 망가져 있습니다.”

“Azure Devops는 제가 사랑하고 싶은 것입니다. UI는 계속 바뀌지만 오래전부터 있어 온 근본적인 버그는 고치지 않습니다.”

“도구들이 잘 통합되어 있지 않고, UI는 정말 느리고, 제가 좋아하는 저장소의 활성 풀 리퀘스트, 빌드, 릴리스 등을 보여 주는 대시보드 뷰도 없습니다. 빌드/배포 시간은 말도 안 되게 느립니다.”

“우리는 Azure Boards(작업 항목, 보드, 백로그 등)도 써 보려고 했습니다. 으윽. 끊어진 아이디어들로 이루어진 완전한 UI 난장판입니다. 한 가지를 잘 구현하는 대신 스무 가지 남짓을 형편없이 구현했습니다.”

Windows 개발 MVP

Windows 개발 MVP입니다. 이러한 문제에 대해 더 크게 목소리를 내지 않은 것에 대해 제가 일부 책임을 져야 한다고 느낍니다. 하지만 UX 문제에 “놀랐다”는 말을 들으니 실망스럽다고 말하지 않을 수 없습니다. 저는 (예를 들어 출시 이전부터) 여러분 팀에게 UX가 끔찍하다고 계속 말해 왔고, 그때마다 “알고 있고, 고치는 중이다”라는 답을 들었습니다. 피드백을 정리해서 파이프라인으로 올려 보내겠습니다. 계속 지켜봐 주십시오. 저도 근처(Bellevue)에 있어서, 찾아가서 비교적 단순한 우리 오픈 소스 .net/wpf/uwp 앱을 파이프라인에 올려 보고 싶습니다. 저희 둘 모두에게 눈이 번쩍 뜨이는 경험이 될 것 같습니다.

몇 가지 예:

• 서브모듈이 포함된 git 저장소로는 파이프라인을 만들 수 없습니다

• 일부 커스텀 도구를 위해 PATH를 편집하는 것이 불가능하다는 것을 알게 되었습니다

• 새 파이프라인 경험은 그냥 말이 되지 않으며, 새 사용자가 이리저리 클릭하다 보면 결국 엉뚱한 문서에 도착합니다.

Edward Thomson(Azure PM) 요약

여러분의 풀 리퀘스트를 병합하는 코드를 작성했습니다. Microsoft의 Azure DevOps 프로그램 매니저이며, 이전에는 GitHub, Microsoft, SourceGear에서 버전 관리 도구를 담당하는 소프트웨어 엔지니어였습니다.

https://www.edwardthomson.com/

libgit2 공동 메인테이너. https://libgit2.github.io

Git에 관한 팟캐스트 All Things Git의 공동 진행자. https://www.allthingsgit.com/

개발 도구에 관한 뉴스레터 Developer Tools Weekly의 큐레이터. https://developertoolsweekly.com/