במשימה הזאת יוצרים את ה‑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, או השאירו …

במשימה הזאת כותבים שלושה קובצי workflow, אחד לכל אירוע: Workflow רץ על התפקיד שלו Branch push ל‑topic branch הלולאה של המפתח עצמו: משוב מהיר תוך כדי עבודה; הוא לא חוסם כלום Pull request pull request ל‑main, וכל commit חדש בו השער: ה‑checks שלו והאישור מחליטים אם שינוי מגיע ל‑main Merge merge לתוך main ‏delivery: מה …

במשימה הזאת main מפסיק לקבל שינויים ישירות: שינוי מגיע אליו רק דרך pull request שעובר את ה‑checks שלו ויש לו אישור. המאשר הוא pr-reviewer, ה‑GitHub App מהקורס Git Collaboration: תחליף לחבר צוות בכיר. בצוות אמיתי, אדם קורא כל 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 לפני …

במשימה הזאת ה‑pull request מריץ את מה שאיטי מדי לכל push. הוסיפו database TODO: ‏PostgreSQL במקום האחסון של משימה 1, או להשאיר SQLite ולדלג על זה. הריצו את ה‑integration tests הפעילו את ה‑image שנבנה ב‑image-build, ו‑database כ‑service container. קראו לכל route דרך HTTP, מקצה לקצה. TODO: להעביר את ה‑image בין jobs: …