במשימה הזאת יוצרים את ה‑repository ואת האפליקציה שה‑pipeline יעביר. צרו את ה‑repository ב‑GitHub, repository חדש ציבורי (public): <you>/devops-project. זה ה‑portfolio שלכם: מעסיק פוטנציאלי יכול לקרוא את הקוד, את ה‑pipeline ואת כל run. משימה 3 מגינה על main עם branch protection rule, ובתוכניות החינמיות של GitHub זה …
המשך קריאהבמשימה הזאת ה‑deployment מקבל את החלקים שיש ל‑deployment אמיתי. הוסיפו environments GitHub environments בשם staging ו‑production, לכל אחד variables ו‑secrets משלו. TODO: required reviewer על production, או רק האישור של ה‑merge. עשו deploy ל‑staging קודם TODO: namespace שני, או קבוצה שנייה של instances. production …
המשך קריאהבמשימה הזאת מסירים את מה שעולה כסף ואת מה שמחזיק credential. הסירו את המשאבים ב‑AWS TODO: terraform destroy, לכל מסלול; בדקו שה‑load balancers נעלמו. הסירו את ה‑credentials ה‑token של Docker Hub, ה‑secrets של ה‑repository, ה‑IAM role וה‑OIDC provider. הסירו את התקנת ה‑app הסירו את pr-reviewer מה‑repository, או השאירו …
המשך קריאהבמשימה הזאת יוצרים שלושה קבצים ב‑.github/workflows/, workflow אחד לכל אירוע: קובץ רץ על התפקיד שלו branch.yml push ל‑topic branch הלולאה של המפתח עצמו: משוב מהיר תוך כדי עבודה; הוא לא חוסם כלום pr.yml pull request ל‑main, וכל commit חדש בו השער: ה‑checks שלו והאישור מחליטים אם שינוי מגיע ל‑main merge.yml merge לתוך …
המשך קריאהבמשימה הזאת main מפסיק לקבל שינויים ישירות: שינוי מגיע אליו רק דרך pull request שיש לו אישור. המאשר הוא pr-reviewer, GitHub App שנכתב בשביל הקורסים של האתר: תחליף לחבר צוות בכיר. בצוות אמיתי, אדם קורא כל pull request, ומאשר רק שינוי שלדעתו נכון. pr-reviewer לעולם לא קורא את הקוד: הוא מבקש שינויים פעם אחת, מחכה …
המשך קריאהבמשימה הזאת ה‑placeholders הראשונים נעשים אמיתיים: ה‑jobs image-build ו‑image-push. ה‑image נבנה על GitHub runner, מכונה חדשה לכל job, לא על המחשב שלכם. רק ה‑workflow של ה‑merge דוחף אותו ל‑Docker Hub. pull request בונה את ה‑image וזורק אותו; topic branch לא בונה בכלל. ה‑push צריך login ל‑Docker Hub, עם token ששמור …
המשך קריאהבמשימה הזאת יוצרים את המקום שבו האפליקציה רצה, ומאפשרים ל‑pipeline להגיע אליו. הכניסו את GitHub Actions ל‑AWS OIDC identity provider ו‑role שרק main של ה‑repository שלכם רשאי לקבל: הצעדים נמצאים ב‑ Pipeline Identities, Part 4 (באנגלית). TODO: Terraform, או ה‑console; ואיפה ה‑state שלו נשמר. העריכו כמה ה‑EKS cluster …
המשך קריאהבמשימה הזאת ה‑pipeline נעשה פתרון שלם: merge ל‑main מעלה את הגרסה החדשה ל‑AWS. כתבו את ה‑job של ה‑deploy קבלו את ה‑role עם aws-actions/configure-aws-credentials. אפשרות 1: EKS Deployment (שני replicas, readiness probe על /healthz) ו‑Service מסוג LoadBalancer, ב‑deploy/. ה‑job מעדכן את ה‑image ל‑tag של ה‑commit ומחכה …
המשך קריאהבמשימה הזאת ה‑placeholders של ה‑workflow של ה‑branch נעשים אמיתיים. הריצו lint על הקוד ruff check ו‑ruff format --check. במסלול FastAPI: גם mypy. הריצו את ה‑unit tests pytest עם coverage; נכשל מתחת לסף. TODO: הסף. actions/setup-python עם caching של pip. matrix של גרסאות Python. TODO: אילו. הריצו את אותם checks לפני …
המשך קריאה