Architecture Decision Record

Active theme: Light

← דוגמאות לרשומות החלטה

Microsoft Azure DevOps

תוכן העניינים:

סיכום

בעיה

אנו רוצים להשתמש ב-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 היא בלגן של ממשקי משתמש, חלקם חופפים לחשבונות Microsoft וחלקם לא. למשל יש התחברות ל-Azure, התחברות ל-Microsoft.com, התחברות ל-Live.com וכדומה, וכולן בו-זמנית במשחק.

  • נתקלנו בבעיית אבטחה קלה במהלך ההקמה, ולא מצאנו פתרון. ניסינו דרכים רבות לדווח עליה, לנציגי Microsoft רבים, ללא הצלחה. דיווחנו עליה בהצלחה לאבטחה של Microsoft, שהשיבה שלא יתוקן.

  • התיעוד לעיתים קרובות שגוי או מיושן. לפחות חלק מזה נובע ממנוע החיפוש הגרוע של Microsoft, וחלק מזה מ-SEO חלש.

  • הקמת Terraform מתועדת היטב ועובדת. עם זאת, התמיכה ב-Terraform חלשה בהשוואה ל-AWS כי Microsoft בונה קשרים עסקיים עם ספקים כדי ליצור דוגמאות הקמה מקצה לקצה דרך Terraform.

הניסיון של עמיתים:

  • אחרי שביצענו הערכה עיוורת משלנו, חיפשנו ניסיון של עמיתים. מה שמצאנו אישר את הניסיון שלנו.

  • עמיתים דיווחו על בעיות נוספות עם זמני בנייה, ובעיות עם הבאת שרת בנייה משלך. הבעיות האלה חמורות משמעותית מבעיות ממשק משתמש, כי ביצוע בניות הוא המטרה המרכזית של צינור בנייה, ואנו מצפים לבצע רבות ביום.

  • מצאנו השתתפות מצוינת של חברי צוות Azure באזורי הדיון. כל הכבוד ל-Microsoft על כך. אנו מתרשמים במיוחד מ-Edward Thomson, מנהל מוצר ומתכנת ב-Azure, בגלל השתתפותו, ישירותו והסברים הטכניים שלו.

השלכות

נראה שבחירה ב-Microsoft Azure DevOps תהיה יקרה יותר (פי ~3) בזמן ובעלות מאשר אי-בחירה ב-Azure.

נושאים קשורים

החלטות קשורות

אם נבחר ב-Azure DevOps, יש הצעות קשורות רבות, כולל Azure Repo, ‏Azure Pipeline וכדומה. אנו מאמינים שאם נבחר ב-Azure Devops, זה עשוי להקל עלינו להשתמש ביכולות Azure נוספות, או להקשות על שימוש ביכולות של ספקים אחרים.

אנו מאמינים ש-Microsoft עושה צעדים גדולים בחוויית המפתח, ואנו רואים את Microsoft מבצעת רכישות גדולות של כלי מפתחים (למשל GitHub) ותלויות (למשל Citus).

אם נבחר ב-Azure DevOps, ייתכן שנרצה להדגיש בחירה בהצעות שנרכשו על ידי Microsoft, וייתכן שנרצה גם לגשת להצעות שנרכשו בזהירות/הערכה רבה יותר בגלל דחיית רקמה אפשרית, למשל סיכון לעזיבת עובדים.

דרישות קשורות

אנו רוצים זמני בנייה מהירים מאוד. אנו מקבלים תשלום פרמיה גבוהה על כך. זאת מפני שאנו רוצים לבצע איטרציות מהירות מאוד.

אנו רוצים אמינות גבוהה מאוד. אנו מקבלים תשלום פרמיה גבוהה על כך. זאת מפני שאנו בודקים מקרי שימוש בעלי ערך גבוה, כולל טרנזקציות פיננסיות, טרנזקציות חסויות וכדומה.

ארבעת מדדי הביצוע המובילים שלנו ב-devops כוללים זמן ממוצע להתאוששות, שמצריך בנייה מהירה ואמינות גבוהה.

תוצרים קשורים

אנו רוצים שמערכת הבנייה תפיק תוצרים מתאימים לשימוש במערכות אחרות, כמו Artifactory.

עקרונות קשורים

הפיך בקלות. אפשר להעריך את Azure DevOps במקביל ל-AWS הנוכחית.

הערות

Microsoft Devops CI: An Unsatisfying Adventure

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 מדורגת אחרונה בפער."

"ממשק המשתמש מסורבל להחריד בכל מקום. הגרוע ביותר מבחינתי הוא pull requests. קשה להפליא לעבוד עם אנשים על pull request. אני אפילו לא יכול להצביע על בעיה מסוימת "אחת" - אצלנו זה שבור בכל מקום."

"Azure Devops היא משהו שאני רוצה לאהוב. ממשק המשתמש ממשיך להשתנות, אבל לא מתקן באגים בסיסיים שקיימים כבר שנים."

"הכלים לא משולבים היטב, ממשק המשתמש ממש איטי, אין תצוגת לוח מחוונים של pull requests פעילים, בניות, שחרורים וכדומה למאגרים האהובים עליי. זמני בנייה/פריסה איטיים בצורה מטורפת."

"ניסינו להשתמש גם ב-Azure Boards (Work Items, Boards, Backlogs וכדומה). אוי. זה בלגן מוחלט של ממשק משתמש עם רעיונות מנותקים. במקום לממש דבר אחד היטב, הם מימשו עשרים וארבעה דברים בצורה גרועה."

Windows Development MVP

Windows Development MVP כאן. אני מרגיש שעליי לשאת בחלק מהאחריות על כך שלא הייתי קולני יותר בנוגע לבעיות האלה. אבל חייב לומר, אני מאוכזב לשמוע שאתם "מופתעים" מבעיות חוויית המשתמש. אני אומר לאנשים שלכם שחוויית המשתמש איומה (למשל עוד לפני ההשקה) ותמיד שמעתי בחזרה "אנחנו יודעים, אנחנו מתקנים". אתחיל לגבש את המשוב באופן רשמי ואעביר אותו בצינורות, הישארו מעודכנים. אני גם מקומי (Bellevue), אשמח לבוא ולנסות להעביר בצינור את יישום ה-oss של .net/wpf/uwp הפשוט יחסית שלנו. אני חושד שזה יפתח את העיניים לשנינו.

כמה דוגמאות:

  • אי אפשר לבנות צינור עם מאגר git שמכיל submodules

  • גיליתי שאי אפשר לערוך את ה-PATH עבור כלים מותאמים

  • חוויית הצינור החדש פשוט לא הגיונית במיוחד, משתמשים חדשים שילחצו מסביב יגיעו בסופו של דבר למסמכי העזרה הלא נכונים.

סיכום של Edward Thomson (מנהל מוצר ב-Azure)

אני כתבתי את הקוד שממזג את ה-pull requests שלכם. מנהל תוכנית ב-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/