Microsoft Azure DevOps

สารบัญ:

• สรุป
  • ประเด็น
  • การตัดสินใจ
  • สถานะ
• รายละเอียด
  • สมมติฐาน
  • ข้อจำกัด
  • จุดยืน
  • ข้อโต้แย้ง
  • นัยยะ
• ที่เกี่ยวข้อง
  • การตัดสินใจที่เกี่ยวข้อง
  • ข้อกำหนดที่เกี่ยวข้อง
  • ผลงานที่เกี่ยวข้อง
  • หลักการที่เกี่ยวข้อง
• หมายเหตุ
  • Microsoft Devops CI: การผจญภัยที่ไม่น่าพอใจ
  • ประเด็นเด่นจากการอภิปรายบน Hacker News
  • Windows Development MVP
  • สรุปโดย Edward Thomson (Azure PM)

สรุป

ประเด็น

เราต้องการใช้ devops เพื่อสร้าง รวม ติดตั้งใช้งาน และโฮสต์โครงการของเรา เรากำลังพิจารณา Microsoft Azure DevOps

• เราต้องการให้ประสบการณ์นักพัฒนารวดเร็วและเชื่อถือได้ ทั้งสำหรับการตั้งค่า devops เช่น การกำหนดค่า และการใช้งานต่อเนื่อง เช่น เวลาสร้างที่เร็ว

• เราต้องการพิจารณาการใช้ Microsoft Azure โดยรวมสำหรับโฮสต์แอปของโครงการ ฐานข้อมูล ฯลฯ

การตัดสินใจ

ตัดสินใจไม่เลือก Microsoft Azure DevOps

สถานะ

ตัดสินใจแล้ว เปิดรับการทบทวนหาก/เมื่อมีข้อมูลใหม่ที่สำคัญเข้ามา

รายละเอียด

สมมติฐาน

สมมติฐาน devops ทั่วไปทั้งหมด เช่น ในหนังสือ Accelerate

• การสร้างที่เร็วช่วยได้มาก ทำให้วงจรข้อเสนอแนะเร็วขึ้น

• เราสลับส่วนของผู้ขายทางเลือกเข้าออกได้ กล่าวคือเราอาจต้องการนำเซิร์ฟเวอร์สร้างที่เร็วกว่าของเราเอง หรือใช้ระบบควบคุมเวอร์ชันที่เราเลือก หรือประสานกับเซิร์ฟเวอร์การรวมระบบอย่างต่อเนื่องที่โฮสต์เอง

• การใช้งานที่คล่องตัวช่วยได้มากสำหรับประสบการณ์นักพัฒนา และส่งผลต่อด้านละเอียดอ่อน เช่น ความสอดคล้อง ความชัดเจน ความปลอดภัย และความง่ายของเส้นโค้งการเรียนรู้

• เมื่อมีสิ่งใดเสียหายหรือเป็นปัญหา เราต้องการวิธีรายงานปัญหาอย่างมีประสิทธิภาพ ซึ่งสำคัญเป็นพิเศษสำหรับปัญหาที่เกี่ยวกับความปลอดภัย

ข้อจำกัด

ไม่ทราบ Azure มีคำมั่นที่เผยแพร่ว่าจะทำงานร่วมกับเครื่องมือภายนอกได้ดี

จุดยืน

เราพิจารณาการใช้ Microsoft Azure Devops เทียบกับ AWS ซึ่งเป็นผู้ให้บริการปัจจุบัน

เราทดลอง Azure DevOps, Azure Pipelines, Azure Repo และการเปิดเซิร์ฟเวอร์ใหม่บน Azure ผ่าน Terraform

เราทดลองขอรับการสนับสนุนจากตัวแทนของ Microsoft

เรารวบรวมข้อมูลจากเพื่อนร่วมวงการบนบล็อกและ Hacker News

ข้อโต้แย้ง

Azure DevOps โฆษณาชุดข้อเสนอที่ยอดเยี่ยม แต่ไม่เป็นไปตามนั้น ทำงานร่วมกันได้ไม่ดี และการสนับสนุนแย่

ประสบการณ์ตรงของเรา:

• การตั้งค่า Azure เป็นความยุ่งเหยิงของ UI บางส่วนทับซ้อนกับบัญชี Microsoft บางส่วนไม่ทับซ้อน เช่น มีการลงชื่อเข้าใช้ Azure การลงชื่อเข้าใช้ Microsoft.com การลงชื่อเข้าใช้ Live.com ฯลฯ และทั้งหมดเกี่ยวข้องพร้อมกัน

• เราพบปัญหาความปลอดภัยเล็กน้อยระหว่างการตั้งค่า และไม่พบวิธีแก้ เราพยายามหลายวิธีเพื่อรายงานต่อตัวแทน Microsoft หลายคน แต่ไม่สำเร็จ เรารายงานต่อฝ่ายความปลอดภัยของ Microsoft ได้สำเร็จ ซึ่งตอบว่าจะไม่แก้ไข (won't fix)

• เอกสารมักผิดหรือล้าสมัย อย่างน้อยส่วนหนึ่งเป็นเพราะเครื่องมือค้นหาที่แย่ของ Microsoft และส่วนหนึ่งเป็นเพราะ SEO ที่ต่ำกว่ามาตรฐาน

• การตั้งค่า Terraform มีเอกสารดีและใช้งานได้ อย่างไรก็ตาม การสนับสนุน Terraform อ่อนเมื่อเทียบกับ AWS เพราะ Microsoft กำลังสร้างความสัมพันธ์ทางธุรกิจกับผู้ขายเพื่อทำตัวอย่างการตั้งค่า Terraform แบบต่อเนื่อง

ประสบการณ์ของเพื่อนร่วมวงการ:

• หลังจากทำการประเมินแบบปิดตาของเราเอง เราค้นหาประสบการณ์ของเพื่อนร่วมวงการ สิ่งที่เราพบยืนยันประสบการณ์ของเรา

• เพื่อนร่วมวงการรายงานปัญหาเพิ่มเติมเกี่ยวกับเวลาสร้างและปัญหากับเซิร์ฟเวอร์สร้างที่นำมาเอง ปัญหาเหล่านี้ร้ายแรงกว่าปัญหา UI อย่างมีนัยสำคัญ เพราะการสร้างเป็นจุดประสงค์หลักของไปป์ไลน์การสร้าง และเราคาดว่าจะทำหลายครั้งต่อวัน

• เราพบการมีส่วนร่วมที่ยอดเยี่ยมของเพื่อนร่วมทีม Azure ในพื้นที่อภิปราย ขอชื่นชม Microsoft สำหรับเรื่องนี้ เราประทับใจเป็นพิเศษกับ Edward Thomson, Azure PM และนักเขียนโปรแกรม เพราะการมีส่วนร่วม ความตรงไปตรงมา และคำอธิบายทางเทคนิคของเขา

นัยยะ

การเลือก Microsoft Azure DevOps ดูเหมือนจะแพงกว่า (~3 เท่า) ในเวลาและต้นทุนเมื่อเทียบกับการไม่เลือก Azure

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

หากเราเลือก Azure DevOps มีข้อเสนอที่เกี่ยวข้องมากมาย รวมถึง Azure Repo, Azure Pipeline ฯลฯ เราเชื่อว่าหากเราเลือก Azure Devops อาจทำให้ใช้ความสามารถของ Azure มากขึ้นได้ง่ายขึ้น หรืออาจทำให้ใช้ความสามารถของผู้ขายรายอื่นยากขึ้น

เราเชื่อว่า Microsoft กำลังก้าวหน้าอย่างมากในประสบการณ์นักพัฒนา และเราเห็น Microsoft เข้าซื้อกิจการเครื่องมือนักพัฒนา (เช่น GitHub) และสิ่งที่พึ่งพา (เช่น Citus) ขนาดใหญ่

หากเราเลือก Azure DevOps เราอาจต้องการเน้นการเลือกข้อเสนอจากการซื้อกิจการของ Microsoft และอาจต้องการเข้าหาข้อเสนอที่ซื้อมาด้วยความระมัดระวัง/การประเมินมากขึ้นเนื่องจากอาจเกิดการปฏิเสธ เช่น ความเสี่ยงที่พนักงานลาออก

ข้อกำหนดที่เกี่ยวข้อง

เราต้องการให้เวลาสร้างเร็วมาก เรายอมจ่ายส่วนเพิ่มสูงสำหรับสิ่งนี้ เพราะเราต้องการวนซ้ำเร็วมาก

เราต้องการให้ความน่าเชื่อถือสูงมาก เรายอมจ่ายส่วนเพิ่มสูงสำหรับสิ่งนี้ เพราะเรากำลังทดสอบกรณีใช้งานมูลค่าสูง รวมถึงธุรกรรมทางการเงิน ธุรกรรมที่เป็นความลับ ฯลฯ

KPI devops สี่อันดับแรกของเรารวมเวลาเฉลี่ยในการกู้คืน ซึ่งต้องการการสร้างที่เร็วและความน่าเชื่อถือสูง

ผลงานที่เกี่ยวข้อง

เราต้องการให้ระบบสร้างส่งออกผลงานที่เหมาะกับการใช้ในระบบอื่น เช่น Artifactory

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย เราประเมิน Azure DevOps ควบคู่ไปกับผู้ให้บริการปัจจุบัน AWS ได้

หมายเหตุ

Microsoft Devops CI: การผจญภัยที่ไม่น่าพอใจ

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

โพสต์บล็อก

"ในฐานะนักพัฒนาซอฟต์แวร์ ฉันรู้จากประสบการณ์ตรงว่าการสร้างผลิตภัณฑ์คุณภาพอย่างรวดเร็วและราคาถูกนั้นยากเพียงใด มันเป็นรูปแบบศิลปะที่บางครั้งเราทำได้ดี และบางครั้งก็เสื่อมลงเป็นบางอย่างคล้ายเว็บไซต์ด้านสุขภาพของรัฐบาลสมัยโอบามา ระดับการควบคุมของเราเหนือผลิตภัณฑ์ที่ได้แตกต่างกัน และความผิดสำหรับความล้มเหลวมักตกที่คนผิดในลำดับชั้นการตัดสินใจ Azure DevOps ของ Microsoft (เดิมเรียกว่า Visual Studio Team Services) แม้จะมีเจตนาดีอย่างชัดเจน ก็เป็นพายุสมบูรณ์แบบของการตัดสินใจที่แย่และการดำเนินการที่ไม่ดี"

ประเด็นเด่นจากการอภิปรายบน Hacker News

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

"เราใช้ Azure DevOps อย่างกว้างขวางที่ที่ทำงานของฉัน และหลังจากใช้ GitHub, Gitlab, โซลูชันที่โฮสต์เอง, Jenkins, TeamCity... Azure DevOps อยู่อันดับสุดท้ายเลย"

"UI เงอะงะอย่างน่ากลัวทุกที่ สิ่งที่แย่ที่สุดสำหรับฉันคือ pull request ยากอย่างไม่น่าเชื่อที่จะทำงานกับผู้คนบน pull request ฉันชี้ไม่ได้แม้แต่ปัญหา "เดียว" โดยเฉพาะ - สำหรับเรามันเสียทุกที่"

"Azure Devops เป็นสิ่งที่ฉันอยากรัก UI เปลี่ยนไปเรื่อย ๆ แต่ไม่แก้บั๊กพื้นฐานที่มีมานานแล้ว"

"เครื่องมือไม่ได้รวมกันดี UI ช้ามาก ไม่มีมุมมองแดชบอร์ดของ pull request ที่ใช้งานอยู่ การสร้าง การเผยแพร่ ฯลฯ สำหรับที่เก็บที่ฉันชอบ เวลาสร้าง/ติดตั้งใช้งานช้าอย่างบ้าคลั่ง"

"เราลองใช้ Azure Boards (Work Items, Boards, Backlogs ฯลฯ) ด้วย โอ๊ย เป็น UI ที่ยุ่งเหยิงสมบูรณ์ของแนวคิดที่ไม่ปะติดปะต่อ แทนที่จะทำสิ่งหนึ่งให้ดี พวกเขาทำสองโหลอย่างแย่"

Windows Development MVP

Windows Development MVP ที่นี่ ฉันรู้สึกว่าต้องรับผิดชอบส่วนหนึ่งที่ไม่ได้ส่งเสียงดังกว่านี้เกี่ยวกับปัญหาเหล่านี้ แต่ต้องบอกว่าผิดหวังที่ได้ยินว่าคุณ "ประหลาดใจ" กับปัญหา UX ฉันบอกคนของคุณว่า UX แย่มาก (เช่น ตั้งแต่ก่อนเปิดตัว) และได้ยินกลับมาเสมอว่า "เรารู้ เรากำลังแก้" ฉันจะเริ่มทำข้อเสนอแนะให้เป็นทางการและส่งผ่านท่อ โปรดติดตาม ฉันอยู่ในท้องถิ่น (Bellevue) ด้วย และอยากไปลองนำแอปโอเพนซอร์ส .net/wpf/uwp ที่ค่อนข้างง่ายของเราเข้าไปป์ไลน์ ฉันสงสัยว่ามันจะเปิดหูเปิดตาให้เราทั้งคู่

ตัวอย่างบางส่วน:

• สร้างไปป์ไลน์กับที่เก็บ git ที่มีโมดูลย่อยไม่ได้

• ฉันพบว่าเป็นไปไม่ได้ที่จะแก้ PATH สำหรับเครื่องมือกำหนดเองบางตัว

• ประสบการณ์ไปป์ไลน์ใหม่ไม่ค่อยสมเหตุสมผล ผู้ใช้ใหม่ที่คลิกไปมาจะจบที่เอกสารผิดในที่สุด

สรุปโดย Edward Thomson (Azure PM)

ฉันเขียนโค้ดที่รวม pull request ของคุณ ผู้จัดการโปรแกรมที่ Microsoft สำหรับ Azure DevOps ก่อนหน้านี้เป็นวิศวกรซอฟต์แวร์ด้านเครื่องมือควบคุมเวอร์ชันที่ GitHub, Microsoft, SourceGear

https://www.edwardthomson.com/

ผู้ร่วมดูแล libgit2 https://libgit2.github.io

พิธีกรร่วมของ All Things Git พอดแคสต์เกี่ยวกับ Git https://www.allthingsgit.com/

ผู้ดูแลเนื้อหาของ Developer Tools Weekly จดหมายข่าวเกี่ยวกับเครื่องมือการพัฒนา https://developertoolsweekly.com/