Codespaces — סביבות פיתוח בענן

4.1 מה זה Codespaces ולמה זה משנה את המשחק

GitHub Codespaces הוא סביבת פיתוח מלאה שרצה בענן. לא עוד "VS Code בדפדפן" — אלא מכונה וירטואלית שלמה עם Docker container שמכיל את הקוד, כל הכלים, כל ה-extensions, וכל ההגדרות. אתם פותחים את הדפדפן (או VS Code Desktop) ותוך שניות יש לכם סביבה זהה לזו של כל חבר צוות.

חישבו על זה כמו Google Docs לקוד: במקום שכל אחד יתקין הכל על המחשב שלו (וישלח הודעה ב-Slack כל שבוע "אצלי זה לא עובד"), כולם עובדים על מכונה זהה שמוגדרת בקובץ אחד. המכונה נמצאת בענן של Azure, ואתם ניגשים אליה דרך VS Code — בדפדפן או באפליקציית Desktop. הקוד מסונכרן עם הריפוזיטורי, ה-extensions מותקנים אוטומטית, והתלויות כבר שם.

למה Codespaces משנה את המשחק? שלוש סיבות:

1. סוף ל-"אצלי זה עובד". כולם עובדים על אותה סביבה בדיוק. אותה מערכת הפעלה (Linux), אותן גרסאות של Node/Python/Java, אותם כלים. מפתח אחד על macOS ואחר על Windows? לא משנה — ה-codespace רץ על Linux container. שינוי ב-devcontainer.json נכנס ל-repo, כל מי שיפתח codespace מקבל את השינוי אוטומטית. אין עוד שעות של debugging שנגרם בגלל הבדלי סביבה.
2. אפס זמן הקמה. מפתח חדש מצטרף לצוות? הוא לוחץ על כפתור אחד ויש לו סביבה עובדת. לא עוד "תקרא את ה-README, תתקין Python 3.11, אל תשכח את pyenv, תעשה pip install, תוריד את ה-.env מ-Notion, ואם אתה על Windows תתקין גם WSL". כל זה נעלם. לחיצה אחת — סביבה מוכנה. עם prebuilds (סעיף 4.4) — תוך 15 שניות.
3. עבודה מכל מקום. Chromebook עם 4GB RAM? iPad עם מקלדת? מחשב של בית הספר שלא נותנים להתקין עליו כלום? מחשב של לקוח שהגעתם לפגישה? כל מה שצריך זה דפדפן ואינטרנט. כל הכוח החישובי הוא בענן — מכונות עם עד 128GB RAM ו-32 ליבות. המחשב המקומי שלכם רק מציג את ה-UI.

מתי Codespaces באמת שימושי בפרקטיקה? הנה חמישה תרחישים שבהם Codespaces חוסך זמן אמיתי:

• Onboarding: מפתח חדש פותח codespace ומתחיל לכתוב קוד תוך 2 דקות במקום יומיים של setup. מישהו מתחיל עבודה ביום ראשון? עד לסוף הבוקר הוא כבר דוחף קוד.
• Code review: פותח codespace על PR branch, מריץ את הקוד, רואה את השינויים live — לא רק קורא diff. אם אתם עושים review רציני, זה כלי שמשנה את האיכות לחלוטין.
• Open source: רוצה לתרום לפרויקט? Fork, Codespace, שינוי, PR. בלי לשכפל ולהתקין. זה מוריד את מחסום הכניסה לתרומות open source באופן דרמטי.
• סדנאות ולימוד: 30 משתתפים — כולם לוחצים על לינק ומקבלים סביבה עובדת. אפס "מי צריך עזרה בהתקנה?". המרצה מתחיל ללמד, לא להתקין.
• ניסויים: רוצים לנסות framework חדש? Template codespace, משחקים שעתיים, מוחקים. בלי לזהם את המחשב המקומי בהתקנות שישכחו שם לנצח.

ארבע דרכים לפתוח Codespace:

1. מריפוזיטורי: כפתור Code הירוק → לשונית Codespaces → Create codespace on main — הדרך הנפוצה ביותר. אפשר גם לבחור branch ספציפי או machine type. אם יש devcontainer.json עם מספר הגדרות — תוכלו לבחור איזו.
2. מ-template: כנסו ל-github.com/codespaces ובחרו template מוכן (React, Next.js, Python, Jupyter, Rust, Preact ועוד). מתאים לפרויקטים חדשים — לא צריך ריפוזיטורי קיים. Template יוצר ריפוזיטורי זמני שאפשר לפרסם אחר כך.
3. מ-PR: בכל PR יש אפשרות לפתוח codespace על הבראנץ' — מושלם ל-code review עם הרצת קוד. לוחצים על Code בדף ה-PR ובוחרים Codespace. אפשר לריץ tests, לראות את ה-UI, לבדוק performance — הכל מתוך ה-review.
4. מ-CLI: gh codespace create -r owner/repo -b main -m basicLinux32gb — מהטרמינל, בלי לפתוח דפדפן. שימושי לסקריפטים ואוטומציות. בפרק 2 למדתם את gh — עכשיו משתמשים בו ליצירת סביבות עבודה.

מה קורה מאחורי הקלעים? כשאתם יוצרים codespace, הנה התהליך המלא:

1. GitHub מקצה מכונה וירטואלית באז'ור (באיזור שבחרתם או הקרוב אליכם גיאוגרפית)
2. בונה Docker container לפי ה-devcontainer.json שלכם (או image ברירת מחדל אם אין devcontainer)
3. מריץ Features — כל תוסף שהגדרתם מותקן בסדר שנקבע לפי תלויות
4. משכפל את הריפוזיטורי לתוך ה-container, כולל submodules אם מוגדר
5. מריץ onCreateCommand — פעולות ראשוניות (database setup, seeding)
6. מריץ postCreateCommand — בדרך כלל npm install או pip install
7. טוען VS Code extensions שהגדרתם ב-customizations
8. מחבר את VS Code (דפדפן או Desktop) ל-container ומפעיל postAttachCommand

כל זה יכול לקחת 30 שניות עד 5 דקות — תלוי בגודל הריפוזיטורי, מספר התלויות, ובעיקר: האם יש prebuilds (נגיע לזה בסעיף 4.4). עם prebuild — רק שלב 7-8 צריכים לרוץ בפתיחה, וכל השאר כבר מוכן.

Codespace = VS Code, אבל איפה?

אפשר להתחבר ל-codespace בשלוש דרכים, וחשוב להבין את ההבדלים כי זה משפיע על חוויית העבודה היומית:

• VS Code בדפדפן: ברירת המחדל. לוחצים "Open in browser" ומקבלים VS Code מלא בטאב של Chrome/Edge. לא צריך להתקין כלום. מתאים ל-90% מהמקרים. יתרון: אפס התקנה. חיסרון: חלק מה-keyboard shortcuts עלולים להתנגש עם shortcuts של הדפדפן (למשל Ctrl+W סוגר טאב).
• VS Code Desktop: אם מותקן אצלכם VS Code, אפשר ללחוץ "Open in VS Code" — האפליקציה נפתחת ומתחברת ל-codespace מרחוק. אותו container בענן, אבל עם חוויית editor מקומית (יותר מהיר, shortcuts עובדים טוב יותר, extensions מקומיות זמינות). דורש extension בשם GitHub Codespaces. זו הדרך המומלצת לעבודה יומיומית אם יש לכם VS Code מותקן.
• JetBrains Gateway: אם אתם מעדיפים IntelliJ/PyCharm/WebStorm — אפשר להתחבר דרך JetBrains Gateway. Codespaces מספק את ה-backend (container עם הקוד והכלים), JetBrains מספק את ה-frontend (ה-IDE שאתם רגילים אליו). שימו לב: JetBrains connection דורש רישיון JetBrains נפרד.

מונחון קצר לפני שממשיכים: codespace שפועל נקרא active — הוא צורך compute. כשאין פעילות למשך idle timeout, הוא עובר ל-stopped — לא צורך compute, אבל עדיין צורך storage (הקוד, התלויות, הקבצים נשמרים). codespace שנמחק — נעלם לגמרי, כולל שינויים שלא נדחפו ל-remote. לכן: תמיד commit ו-push לפני מחיקה.

4.2 devcontainer.json — הקובץ שקובע הכל

בלי devcontainer.json, GitHub בוחר image ברירת מחדל — מכונת Linux עם כמה כלים בסיסיים (Git, Node, Python, כמה כלי CLI). זה עובד לניסוי מהיר, אבל זה לא הסביבה שלכם. חסרים ה-extensions שאתם רגילים אליהם, חסרה הגרסה הספציפית של השפה, חסרים הכלים שהפרויקט צריך, ו-ports לא מוגדרים. כל מפתח שפותח codespace מקבל סביבה "גנרית" שצריך להתאים ידנית.

קובץ devcontainer.json הוא ההגדרה המרכזית שאומרת ל-Codespaces (ול-VS Code Dev Containers מקומי) בדיוק מה לבנות. חשבו עליו כמו package.json לסביבת הפיתוח: הוא מגדיר את ה-base image (מערכת ההפעלה + שפה), את הכלים הנוספים (Features), את ה-extensions שצריך, את הגדרות ה-editor, את ה-ports שהפרויקט משתמש בהם, ואת הפקודות שרצות אחרי ההקמה. הקובץ נכנס ל-version control ביחד עם הקוד — מה שאומר שכל שינוי בסביבה עובר review כמו כל שינוי אחר בקוד.

חשוב: devcontainer.json הוא לא רק ל-Codespaces. זה סטנדרט פתוח שנקרא Dev Containers. אם אתם משתמשים ב-VS Code מקומי עם Docker, אותו קובץ בדיוק יבנה לכם container זהה על המחשב שלכם. סטנדרט אחד, שני מצבי עבודה. זה אומר שההשקעה בכתיבת devcontainer.json משתלמת גם אם לא תשתמשו ב-Codespaces — כל המפתחים בצוות יקבלו סביבה זהה.

איפה שמים את הקובץ?

המיקום הסטנדרטי הוא .devcontainer/devcontainer.json בשורש הריפוזיטורי. GitHub מחפש קודם כל שם, ואם לא מוצא — מחפש .devcontainer.json בשורש (בלי תיקייה). אם יש לכם מונוריפו עם מספר סביבות שונות, אפשר ליצור תיקיות נפרדות: .devcontainer/frontend/devcontainer.json ו-.devcontainer/backend/devcontainer.json — כשפותחים codespace, GitHub ישאל איזו הגדרה לבחור. המלצה: גם אם יש לכם הגדרה אחת בלבד, שימו אותה בתיקייה .devcontainer/ — זה מאפשר להוסיף קבצים נלווים (כמו Dockerfile) בצורה מאורגנת.

הנה devcontainer.json מלא לפרויקט Node.js — עם הסבר לכל שורה:

{
  // שם הסביבה — מופיע ב-UI כשפותחים codespace
  "name": "My Project Dev Environment",

  // Base image — מכיל מערכת הפעלה + כלים בסיסיים
  "image": "mcr.microsoft.com/devcontainers/javascript-node:1-22",

  // Features — תוספות מודולריות (סעיף 4.3)
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },

  // VS Code extensions שיותקנו אוטומטית בכל codespace
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "ms-azuretools.vscode-docker",
        "eamodio.gitlens"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode",
        "terminal.integrated.defaultProfile.linux": "zsh"
      }
    }
  },

  // Ports שייפתחו אוטומטית
  "forwardPorts": [3000, 5432],
  "portsAttributes": {
    "3000": {"label": "App", "onAutoForward": "openBrowser"},
    "5432": {"label": "Database", "onAutoForward": "silent"}
  },

  // פקודה שרצה אחרי יצירת ה-container
  "postCreateCommand": "npm install",

  // פקודה שרצה בכל פעם שנכנסים ל-codespace
  "postAttachCommand": "npm run dev &",

  // משתמש ברירת מחדל — לא root (מומלץ מבחינת אבטחה)
  "remoteUser": "node"
}

בואו נפרק את החלקים החשובים בפירוט:

image — ה-base image שעליו הסביבה בנויה. Microsoft מתחזקת images רשמיים עבור כל שפה נפוצה, תחת הכתובת mcr.microsoft.com/devcontainers/. ה-images האלה מבוססים על Debian/Ubuntu ומכילים את השפה + כלים בסיסיים + Git + כמה CLI tools שימושיים:

טיפ על גרסאות: המספר אחרי הנקודתיים הוא תג הגרסה. 1-22 = גרסה 1 של ה-image עם Node 22. אפשר גם לציין :latest (תמיד הכי חדש) או :1 (major version בלבד — מקבל עדכונים שלא שוברים). ההמלצה: ציינו גרסה ספציפית של השפה (כמו 1-22) כדי שה-build יהיה reproducible.

אם ה-images המוכנים לא מספיקים, אפשר להשתמש ב-Dockerfile משלכם: "build": {"dockerfile": "Dockerfile"}. ה-Dockerfile שמים בתיקיית .devcontainer/ ליד ה-devcontainer.json. הוא יכול לרשת מ-image רשמי ולהוסיף כלים ספציפיים — למשל ספריות C שצריכים קומפילציה, או כלים ייעודיים שלא קיימים כ-Feature.

customizations.vscode — ההגדרות של VS Code בתוך ה-codespace. שני חלקים חשובים:

• extensions — רשימת extension IDs שיותקנו אוטומטית. איפה מוצאים את ה-ID? בדף ה-extension ב-VS Code Marketplace, או בתוך VS Code: קליק ימני על extension → "Copy Extension ID". כל מפתח שיפתח codespace יקבל את ה-extensions האלה מותקנים ומוכנים — בלי לבקש ממנו להתקין כלום. שימו רק extensions שנדרשים לפרויקט — ESLint, Prettier, Language support. לא extensions אישיים כמו themes — אלה שייכים ל-dotfiles (סעיף 4.7).
• settings — כל setting של VS Code שתרצו. editor.formatOnSave, editor.tabSize, terminal.integrated.defaultProfile.linux — כל מה שחשוב לצוות. זה מבטיח שכולם עובדים עם אותו formatter, אותו linter, אותו tab size. טיפ: אפשר גם להגדיר settings ברמת שפה ספציפית — למשל "[python]": {"editor.tabSize": 4}.

forwardPorts + portsAttributes — ports שהסביבה צריכה לשרתי פיתוח, בסיסי נתונים, ושירותים אחרים. forwardPorts מגדיר אילו ports לפתוח. portsAttributes מגדיר התנהגות לכל port: openBrowser (פותח דפדפן אוטומטית כשהשרת עולה), notify (מראה notification), silent (פותח בשקט), ignore (מתעלם לגמרי). נרחיב על port forwarding בסעיף 4.6.

Lifecycle commands — פקודות שרצות בשלבים שונים:

זה אחד החלקים שהכי חשוב להבין טוב, כי ההבדלים דקים אבל קריטיים — במיוחד כשעובדים עם prebuilds:

ההבדל חשוב: onCreateCommand רץ פעם אחת — ונכלל ב-prebuild. postCreateCommand רץ אחרי שהמפתח פותח את ה-codespace — לא נכלל ב-prebuild. אם אתם רוצים dev server שעולה אוטומטית כל פעם — שימו אותו ב-postAttachCommand. אם אתם רוצים שההתקנות הכבדות יהיו חלק מה-prebuild — שימו אותן ב-onCreateCommand. זה ההבדל בין 15 שניות ל-5 דקות פתיחה.

remoteUser — באיזה משתמש לרוץ בתוך ה-container. ברירת המחדל ברוב ה-images היא משתמש שאינו root (כמו node, vscode). זה מומלץ מבחינת אבטחה — לא לעבוד כ-root בתוך ה-container. אם צריכים root לפקודה ספציפית, השתמשו ב-sudo.

4.3 Features — תוספות מוכנות בקליק

במקום לכתוב 20 שורות ב-Dockerfile כדי להתקין Python, Docker-in-Docker או kubectl — אתם מוסיפים שורת JSON אחת. Dev Container Features הן יחידות התקנה מודולריות שמריצות סקריפט התקנה מוכן ומוגדרות דרך features ב-devcontainer.json.

למה Features ולא Dockerfile? שלוש סיבות: (1) פשטות — שורת JSON אחת במקום סקריפט התקנה שצריך לדבג. (2) קומפוזביליות — אפשר לשלב כמה features ביחד בלי קונפליקטים, כי הם תוכננו לעבוד יחד. (3) תחזוקה — הצוות שמתחזק את ה-feature מעדכן אותו לגרסאות חדשות, אתם מקבלים אותן אוטומטית. לא צריך לעדכן סקריפטי התקנה כל פעם שיוצאת גרסה חדשה של Node או Python.

הרגיסטרי הראשי: ghcr.io/devcontainers/features/ — מתוחזק על ידי Microsoft עם מאות features. מעבר לזה, יש רגיסטרי קהילתי ב-github.com/devcontainers-extra/features, וכל אחד יכול לפרסם features משלו. כל feature חי בריפוזיטורי GitHub, עם תיעוד, issues, ו-changelog.

Features נפוצים:

איך Features עובדים מאחורי הקלעים: כל feature הוא תיקייה עם שני קבצים עיקריים: devcontainer-feature.json (מטאדטה, אופציות, תלויות) ו-install.sh (סקריפט ההתקנה). כשה-container נבנה, Codespaces מריץ את סקריפטי ההתקנה של כל ה-features לפי סדר מוגדר. אפשר להעביר אופציות — לדוגמה "version": "22" ל-Node או "installMaven": "true" ל-Java. כל אופציה מתועדת ב-feature.json ומופיעה גם ב-IntelliSense של VS Code כשעורכים את devcontainer.json.

דוגמה קונקרטית: פרויקט Full-stack שצריך Node לפרונט, Python ל-API, ו-Docker ל-database:

"features": {
  "ghcr.io/devcontainers/features/node:1": {
    "version": "22"
  },
  "ghcr.io/devcontainers/features/python:1": {
    "version": "3.12",
    "installTools": true
  },
  "ghcr.io/devcontainers/features/docker-in-docker:2": {
    "dockerDashComposeVersion": "v2"
  },
  "ghcr.io/devcontainers/features/github-cli:1": {}
}

שימו לב: ה-base image יכול להיות mcr.microsoft.com/devcontainers/base:ubuntu (מכונת Linux בסיסית), וה-features מוסיפים את כל הכלים. זה מאפשר שילובים מותאמים שלא קיימים כ-images מוכנים. זה גם מאפשר לכם לשלוט בגרסה המדויקת של כל כלי בנפרד.

Features מתקדמים שכדאי להכיר:

• docker-outside-of-docker — במקום Docker-in-Docker (Docker daemon בתוך ה-container), זה מחבר את ה-container ל-Docker daemon של ה-host. יותר מהיר, פחות תקורה, אבל פחות מבודד.
• sshd — מפעיל SSH server ב-codespace. מאפשר חיבור מכל SSH client, לא רק VS Code.
• desktop-lite — מתקין desktop environment (Fluxbox) עם VNC. מאפשר להריץ אפליקציות GUI ב-codespace ולראות אותן דרך הדפדפן. שימושי ל-Selenium, Cypress, או כל בדיקה שצריכה דפדפן אמיתי.

טיפ: אם אתם צריכים feature שלא קיים ברגיסטרי — בדקו ב-github.com/devcontainers/features ואם לא מוצאים, אפשר ליצור feature משלכם ולפרסם אותו. כל feature הוא בעצם תיקייה עם סקריפט Bash — זה לא מסובך. המבנה: devcontainer-feature.json (מטאדטה) + install.sh (התקנה). אפשר לפרסם ברגיסטרי GHCR כדי שאחרים ישתמשו.

4.4 Prebuilds — הכנה מראש להפעלה מיידית

בלי prebuilds, כל פתיחת codespace עוברת את כל התהליך: clone → build image → install features → install dependencies → configure extensions. על ריפוזיטורי של חברה עם 500 dependencies ב-package.json ו-Dockerfile מורכב, זה יכול לקחת 3 עד 5 דקות. זה לא נשמע הרבה, אבל תחשבו: כל PR review, כל פעם שצריכים codespace חדש, כל סדנה עם 20 משתתפים — 5 דקות של חיכוי כפול 20 אנשים = 100 דקות מבוזבזות. עם prebuilds — 15 שניות לכל אחד.

מה prebuild עושה: GitHub מריץ את כל שלבי ההקמה מראש — ברקע, בכל push ל-branch שהגדרתם. התוצאה היא image מוכן שכולל את הקוד, התלויות, ה-extensions, וכל מה ש-onCreateCommand ו-updateContentCommand עושים. כשמפתח פותח codespace, הוא מקבל את ה-image המוכן מיידית — בלי להמתין לשום התקנה. רק postCreateCommand, postStartCommand ו-postAttachCommand רצים בפתיחה — ואלה בדרך כלל מהירים.

איך מגדירים prebuild — שלב אחר שלב:

1. נכנסים ל-Settings של הריפוזיטורי (צריך admin access)
2. בתפריט הצד: Codespaces
3. תחת Prebuilds לוחצים "Set up prebuild"
4. בוחרים branch (בדרך כלל main) ו-configuration file (אם יש יותר מאחד)
5. בוחרים מתי לרענן: Every push (מומלץ לרוב), On configuration change (רק כש-devcontainer.json משתנה), או Schedule (בזמנים קבועים)
6. בוחרים region/s (בחרו את האיזור הקרוב לרוב המפתחים שלכם — US East, Europe West, וכדומה)
7. לוחצים Create ומחכים ש-prebuild ראשון ירוץ

מה קורה מאחורי הקלעים: כל push ל-branch שהגדרתם מפעיל GitHub Actions workflow (בלי שאתם צריכים לכתוב אותו — GitHub יוצר אותו אוטומטית). ה-workflow מקצה מכונה, בונה container, מריץ את onCreateCommand ו-updateContentCommand, ושומר את ה-image כ-prebuild artifact. כשמפתח פותח codespace — הוא מקבל את ה-image המוכן, בלי לחכות לשום build. אם הייתם בפרק 1 (Actions), זה אותו עיקרון — workflow שרץ ברקע.

מה נכלל ב-prebuild ומה לא:

טיפ קריטי: שימו את ההתקנות הכבדות (npm install, pip install) ב-onCreateCommand — לא ב-postCreateCommand. זה ההבדל בין prebuild שחוסך 4 דקות לבין prebuild שחוסך 30 שניות בלבד. חישבו: מה צריך secrets? רק זה הולך ל-postCreateCommand. כל השאר — ל-onCreateCommand.

4.5 Machine Types — בחירת המכונה הנכונה

כשאתם פותחים codespace, אתם בוחרים את גודל המכונה. הבחירה משפיעה על ביצועים ועל עלות — ההבדל בין 2-core ל-32-core הוא פי 16 במחיר. רוב המפתחים בוחרים מכונה גדולה מדי "ליתר ביטחון" ומשלמים כפול על ביצועים שהם לא צריכים. הסעיף הזה יעזור לכם לבחור נכון.

הערה חשובה על GPU: עד אוגוסט 2025 הייתה אפשרות ל-GPU machine type (ניסיוני, לא זמין באופן כללי). האפשרות בוטלה עקב הפסקת סדרת Azure NCv3 VMs. נכון ל-2026, אין GPU option ב-Codespaces. אם אתם צריכים GPU לעבודה עם ML/AI, הגישה המומלצת היא: כתבו קוד ב-Codespaces (שלא צריך GPU), הריצו training ב-Google Colab, Azure ML, או AWS SageMaker. או פשוט השתמשו במחשב מקומי עם GPU.

איך ה-machine type משפיע על העבודה בפועל? כמה דוגמאות מהשטח:

• 2-core (8GB RAM): מספיק לכתיבת קוד, code review, dev server בודד (React/Vue/Express). VS Code רץ חלק. תתחילו להרגיש איטיות רק עם TypeScript compilation כבדה או כשיש הרבה extensions טעונים.
• 4-core (16GB RAM): הנקודה המתוקה לרוב הפרויקטים. מריץ dev server + linter + tests בלי בעיה. מספיק ל-Docker Compose עם 2-3 services.
• 8-core (32GB RAM): הכרחי כשיש 4+ Docker containers רצים במקביל, או Webpack/Vite build של מונוריפו גדול.
• 16-core ומעלה: רק לפרויקטים ממש גדולים — Android builds, compilation של פרויקטי C++/Rust גדולים, data processing שרץ בתוך ה-codespace.

איך לשנות machine type של codespace קיים? לא חייבים למחוק ולפתוח מחדש. יש שתי דרכים:

• מ-UI: כנסו ל-github.com/codespaces, לחצו על שלוש הנקודות ליד ה-codespace, ובחרו "Change machine type". ה-codespace ייעצר ויעלה מחדש עם ה-machine החדש. הקוד והשינויים נשמרים.
• מ-CLI: gh codespace edit -m standardLinux32gb -c CODESPACE_NAME

איך לקבוע machine type ברירת מחדל לריפוזיטורי: אפשר להגדיר ב-devcontainer.json את ה-machine type המינימלי: "hostRequirements": {"cpus": 4, "memory": "16gb"}. ככה כשמפתח פותח codespace, GitHub לא ייתן לו לבחור מכונה קטנה מדי. זה שימושי לפרויקטים שבאמת דורשים משאבים מינימליים — למשל Docker Compose עם 4 services.

4.6 Port Forwarding — גישה לשרתים מהדפדפן

כשאתם מריצים npm run dev ב-codespace והשרת עולה על port 3000 — אתם לא יכולים לפתוח localhost:3000 בדפדפן המקומי שלכם. למה? כי הקוד לא רץ על המחשב שלכם — הוא רץ על מכונה וירטואלית באז'ור. כאן נכנס port forwarding: Codespaces יוצר URL מיוחד (משהו כמו https://username-repo-abc123-3000.app.github.dev) שמנתב ל-port 3000 ב-container. אתם פותחים את ה-URL בדפדפן ורואים את האפליקציה כאילו היא רצה מקומית.

זה עובד גם ל-preview של אתרים, גם ל-API testing (Postman / Insomnia / Thunder Client נגד ה-URL של Codespaces), וגם לשיתוף מהיר: שולחים ל-PM את ה-URL והוא רואה את ה-feature בזמן אמת. זה כלי שיווקי מדהים — במקום "תמתין שנעלה ל-staging", אפשר להראות feature תוך שניות.

שלושה אופנים של port forwarding:

1. אוטומטי: Codespaces מזהה כש-process מקשיב על port ומציע forwarding. מופיע כ-toast notification ב-VS Code עם כפתור "Open in Browser". רוב השרתים מזוהים אוטומטית — React dev server, Express, Django, Flask.
2. ידני: בפאנל Ports (בתחתית VS Code, ליד Terminal) לוחצים "Forward a Port" ומקלידים מספר. שימושי כשיש port שלא מזוהה אוטומטית.
3. הגדרה קבועה: ב-devcontainer.json עם forwardPorts — הכי מומלץ כי כולם מקבלים את אותם ports, עם label ו-behavior מוגדרים.

Visibility — מי יכול לגשת ל-URL:

• private (ברירת מחדל) — רק אתם, עם אימות GitHub. אף אחד אחר לא יכול לגשת ל-URL, גם אם יש לו אותו.
• org — כל חברי הארגון שלכם ב-GitHub. שימושי לשיתוף פנימי בצוות.
• public — כל אחד עם ה-URL. שימו לב: אל תשתמשו ב-public אם יש data רגיש, כי כל מי שיש לו את ה-URL יכול לגשת. מתאים רק ל-demos, static sites, ופרויקטים ציבוריים.

הגדרה ב-devcontainer.json:

"forwardPorts": [3000, 8080, 5432],
"portsAttributes": {
  "3000": {
    "label": "Frontend",
    "onAutoForward": "openBrowser",
    "protocol": "https"
  },
  "8080": {
    "label": "API",
    "onAutoForward": "notify"
  },
  "5432": {
    "label": "PostgreSQL",
    "onAutoForward": "silent"
  }
}

onAutoForward שולט במה שקורה כשה-port נפתח: openBrowser פותח דפדפן אוטומטית (מומלץ ל-dev server ראשי), notify מראה notification עם לינק ללחוץ (מומלץ ל-APIs), silent פותח בשקט בלי להודיע, ignore מתעלם לגמרי (לשירותי רקע כמו database — כי אתם לא פותחים PostgreSQL בדפדפן).

טיפ מעשי: אם יש לכם Frontend + API + Database, הגדירו את ה-Frontend כ-openBrowser, את ה-API כ-notify, ואת ה-Database כ-ignore. ככה בכל פעם שתעלו את ה-codespace, הדפדפן ייפתח אוטומטית על הפרונט, תקבלו notification עם לינק ל-API, וה-database יעבוד ברקע בשקט.

Port forwarding מ-CLI: אפשר גם לשלוט ב-ports מהטרמינל המקומי (לא מתוך ה-codespace): gh codespace ports forward 3000:3000 — מנגיש את port 3000 ב-codespace ל-localhost:3000 על המחשב המקומי שלכם. שימושי כשעובדים עם VS Code Desktop ורוצים לגשת ל-port כאילו הוא מקומי.

בעיות נפוצות ופתרונות:

• הדפדפן מציג שגיאה "This site can't be reached": השרת שלכם מקשיב על 127.0.0.1 (localhost) במקום על 0.0.0.0 (all interfaces). שנו את ה-host ב-dev server ל-0.0.0.0. לדוגמה ב-Next.js: next dev -H 0.0.0.0.
• Port לא מזוהה אוטומטית: הוסיפו אותו ל-forwardPorts ב-devcontainer.json, או העבירו ידנית מפאנל Ports.
• CORS errors: ה-URL של Codespaces שונה מ-localhost. אם ה-API שלכם בודק CORS, הוסיפו את *.app.github.dev לרשימת ה-allowed origins בסביבת פיתוח.

4.7 Dotfiles ו-Secrets — העדפות אישיות וערכים רגישים

כל פעם שאתם פותחים codespace חדש — הטרמינל נראה "גנרי". אין את ה-aliases שלכם (איפה gs ל-git status?), אין את ה-zsh theme שאתם רגילים אליו, אין את ה-Git config עם השם והמייל, אין את ה-vim settings. כל codespace חדש = הגדרה מחדש. אלא אם כן הגדרתם Dotfiles.

Dotfiles ("קבצי נקודה") הם קבצי הגדרות שמתחילים בנקודה — .zshrc, .bashrc, .gitconfig, .vimrc, .aliases. הרעיון: אתם יוצרים ריפוזיטורי אחד עם כל ההגדרות האישיות שלכם, ו-Codespaces משכפל אותו אוטומטית לכל codespace חדש שאתם פותחים. הריפוזיטורי הזה שייך לכם — לא לפרויקט. ככה devcontainer.json מגדיר את סביבת הפרויקט (כלים, extensions, ports), ו-dotfiles מגדירים את ההעדפות האישיות שלכם (aliases, shell theme, editor config). ההפרדה הזאת חשובה: הפרויקט לא צריך לדעת שאתם מעדיפים Oh My Zsh עם theme ספציפי.

הגדרת dotfiles — שלב אחר שלב:

1. צרו ריפוזיטורי בשם dotfiles (או כל שם אחר — my-dotfiles, .config) בחשבון שלכם. מומלץ שהריפוזיטורי יהיה public — אין בו secrets, וככה אתם גם עוזרים לאחרים לקבל רעיונות.
2. הוסיפו קבצי הגדרות: .zshrc, .gitconfig, .aliases, .vimrc — מה שחשוב לכם. התחילו קטן — 3-4 קבצים מספיקים.
3. הוסיפו סקריפט התקנה: install.sh (או setup.sh / bootstrap.sh) — Codespaces יריץ אותו אוטומטית. הסקריפט צריך ליצור symlinks מהקבצים בריפוזיטורי לנתיב הנכון ב-home directory.
4. כנסו ל-GitHub Settings → Codespaces → סמנו "Automatically install dotfiles" ובחרו את הריפוזיטורי.
5. פתחו codespace חדש ובדקו שה-aliases עובדים, ה-shell נראה כמו שאתם רוצים, וה-git config תקין.

דוגמה ל-install.sh מינימלי:

#!/bin/bash
# Symlink dotfiles to home directory
DOTFILES_DIR="$(cd "$(dirname "$0")" && pwd)"

ln -sf "$DOTFILES_DIR/.zshrc" ~/.zshrc
ln -sf "$DOTFILES_DIR/.gitconfig" ~/.gitconfig
ln -sf "$DOTFILES_DIR/.aliases" ~/.aliases

# Source aliases in current shell
if [ -f ~/.aliases ]; then
  echo "source ~/.aliases" >> ~/.zshrc
fi

# Set default shell to zsh (if not already)
if [ "$SHELL" != "/bin/zsh" ]; then
  sudo chsh -s /bin/zsh $(whoami) 2>/dev/null || true
fi

echo "Dotfiles installed successfully!"

דוגמה ל-.aliases שימושי:

# Git shortcuts
alias gs='git status'
alias ga='git add'
alias gc='git commit'
alias gp='git push'
alias gl='git log --oneline -20'
alias gd='git diff'

# Navigation
alias ..='cd ..'
alias ...='cd ../..'
alias ll='ls -la'

# GitHub CLI
alias ghpr='gh pr create'
alias ghprl='gh pr list'
alias ghcs='gh codespace list'

Secrets — ערכים רגישים:

API keys, tokens, סיסמאות, connection strings — כל אלה צריכים להיות נגישים ב-codespace אבל לא בקוד. כזכור, ב-Warning בסעיף 4.2 הזהרנו שלא לשים secrets ב-devcontainer.json. אז איך מעבירים ערכים רגישים? Codespaces Secrets הם משתני סביבה מוצפנים שנשמרים בהגדרות GitHub שלכם (לא בריפוזיטורי!) וזמינים בכל codespace.

הגדרת secret — שלב אחר שלב:

1. כנסו ל-GitHub Settings (לחיצה על אווטר → Settings)
2. בתפריט הצד: Codespaces
3. תחת "Codespaces secrets" לחצו "New secret"
4. הקלידו שם (DATABASE_URL) וערך (postgresql://user:pass@host:5432/db)
5. בחרו לאילו ריפוזיטורים ה-secret נגיש — אפשר "All repositories" או רשימה ספציפית. המלצה: בחרו רשימה ספציפית — כל secret צריך להיות נגיש רק לריפוזיטורים שבאמת צריכים אותו.
6. ב-codespace, ה-secret זמין כ-$DATABASE_URL בטרמינל ובקוד. בדקו עם echo $DATABASE_URL.

שלושה סוגי secrets:

• User secrets — ברמת user. כל מפתח מגדיר secrets משלו. זמינים רק ב-codespaces שהמפתח יוצר. זה מה שתיארנו למעלה.
• Organization secrets — ברמת org. מוגדרים ע"י org admin ונגישים לכל חברי הארגון (או לקבוצות ספציפיות). שימושי ל-secrets משותפים כמו shared staging API key.
• Repository secrets — ברמת repo. מוגדרים בהגדרות הריפוזיטורי (Settings → Secrets and variables → Codespaces). נגישים לכל מי שיוצר codespace על הריפוזיטורי הזה. שימושי ל-secrets ספציפיים לפרויקט.

טיפ מתקדם: אפשר להגדיר ב-devcontainer.json ש-secrets ספציפיים נדרשים באמצעות "secrets" property. אם מפתח יפתח codespace בלי להגדיר אותם, Codespaces יציג התראה עם הוראות. ככה אתם מבטיחים שכל מי שפותח codespace לפרויקט ידע שהוא צריך להגדיר AWS_ACCESS_KEY וכדומה.

4.8 עלויות וכיבוי אוטומטי — כל שקל חשוב

Codespaces הוא לא חינמי ללא הגבלה. יש free tier נדיב שמספיק לרוב המשתמשים הקזואליים, אבל מי שלא שם לב יכול להיתקע בהפתעות — במיוחד אם משאיר codespace דלוק על מכונה גדולה או שוכח codespaces ישנים שתופסים storage. בואו נבין בדיוק מה חינמי, מה עולה, איך לחשב, ואיך למנוע בזבוז.

שני סוגי עלות:

1. Compute (חישוב) — לפי שעת ריצה x מספר ליבות. נמדד ב-core-hours. זה העלות העיקרית — כל רגע שה-codespace פעיל (גם idle!) צורך core-hours. הקלדתם שורה ולכתם לארוחת צהריים? ה-codespace עדיין רץ ועדיין צורך. עד שה-idle timeout נכנס לפעולה.
2. Storage (אחסון) — לפי GB שה-codespace תופס על הדיסק. נמדד ב-GB-months ($0.07 ל-GB בחודש). זה כולל קוד, תלויות (node_modules יכול להיות 1-2GB לבדו!), Docker images, וכל מה שנמצא ב-container — גם כשהוא כבוי. כלומר: codespace עצור לא צורך compute, אבל כן צורך storage.

Free tier — מה מקבלים בחינם:

מה זה core-hours? שעה אחת על מכונת 4-core = 4 core-hours. אם יש לכם 120 core-hours ואתם עובדים על 4-core, יש לכם 30 שעות עבודה בחודש. על 2-core — 60 שעות. על 8-core — רק 15 שעות. הנוסחה פשוטה: שעות = core-hours / מספר ליבות. לכן בחירת machine type קטן יותר לא רק חוסכת כסף — היא גם נותנת לכם יותר שעות עבודה מה-free tier.

תרחישי עלות חודשית — מספרים אמיתיים:

* $0.09 = עלות per-core-hour ($0.18/hr / 2 cores)

שימו לב לתרחיש האחרון: מפתח שעובד full-time על 32-core (בלי סיבה מוצדקת) משלם $450 בחודש. אותו מפתח על 4-core משלם $47. ההבדל: $400+ בחודש, $4,800 בשנה. לכן בחירת machine type נכונה היא לא רק עניין טכני — זה עניין כספי.

כיבוי אוטומטי — idle timeout:

• ברירת מחדל: 30 דקות חוסר פעילות
• טווח: 5 דקות עד 240 דקות (4 שעות)
• מה נחשב פעילות: הקלדה, עכבר, input/output בטרמינל. בניית קוד ברקע כן נחשבת פעילות.
• מה לא נחשב: dev server שרץ בשקט בלי שנוגעים בו — אחרי 30 דקות ייכבה
• איפה משנים: Settings → Codespaces → "Default idle timeout"
• המלצה: הורידו ל-15 דקות או פחות. אם צריכים יותר לפעולה ספציפית (למשל build ארוך) — שנו זמנית ב-codespace הספציפי

Retention period — כמה זמן codespace עצור נשמר:

• ברירת מחדל: 30 יום
• טווח: 0 עד 30 יום (0 = מחיקה מיידית עם עצירה)
• למה חשוב: codespace עצור עדיין צורך storage ואתם משלמים $0.07/GB בחודש. אם יש לכם 5 codespaces עצורים שתופסים 10GB כל אחד — זה 50GB x $0.07 = $3.50 לחודש על כלום.
• המלצה: הורידו ל-7 ימים או פחות. עם prebuilds, פתיחת codespace חדש היא מהירה בכל מקרה — אין צורך לשמור ישנים "ליתר ביטחון"

Spending limit — הגדרת תקרה:

ברירת מחדל: $0. זה אומר שכשה-free tier נגמר, אי אפשר ליצור codespaces חדשים ו-codespaces פעילים ייעצרו. אם אתם רוצים להמשיך — הגדירו spending limit ב-Settings → Billing → Codespaces. אפשר סכום מוגבל ($10, $50) או unlimited. לעולם אל תגדירו unlimited אלא אם אתם ארגון עם תקציב מוגדר וניטור — זה מתכון להפתעות.

8 טיפים לחיסכון בעלויות:

1. הורידו idle timeout ל-15 דקות או פחות. ברירת מחדל של 30 דקות זו חצי שעה שאתם משלמים על כלום כל פעם שאתם הולכים לקפה. 15 דקות מספיק לשיחת טלפון קצרה בלי שה-codespace ייכבה.
2. הורידו retention period ל-7 ימים. codespace עצור עדיין תופס storage (ומשלמים!). עם prebuilds, פתיחת codespace חדש היא כמעט מיידית — אין צורך לשמור ישנים.
3. התחילו עם 2-core. לרוב העבודות (עריכת קוד, code review, dev server בודד) 2-core מספיק בהחלט. שדרגו רק אם מרגישים איטיות ממשית — לא "ליתר ביטחון".
4. עצרו ידנית בסוף היום. אל תסגרו את הטאב בדפדפן — זה לא עוצר את ה-codespace! סגירת טאב = ה-codespace ממשיך לרוץ ולצרוך core-hours עד ל-idle timeout. השתמשו ב-Codespaces: Stop Current Codespace מה-Command Palette, או gh codespace stop מהטרמינל.
5. מחקו codespaces שלא בשימוש. נכנסו ל-github.com/codespaces ומחקו את מה שלא צריך. כל codespace ברשימה תופס storage — גם אם הוא עצור.
6. שקלו Pro ($4/חודש). אם אתם מתקרבים ל-120 core-hours, שדרוג ל-Pro נותן 180 core-hours + 20GB storage — ההבדל של 60 core-hours שווה $5.40 (60 x $0.09), כלומר Pro חוסך לכם $1.40 בחודש כבר מהרגע הראשון שעוברים את ה-free tier.
7. הגדירו spending limit. גם אם החלטתם לשלם מעבר ל-free tier, הגדירו תקרה ($20, $50) כדי שלא תהיינה הפתעות בסוף החודש.
8. נטרו ב-Billing. בדקו את דף ה-Billing פעם בשבוע. אם אתם צורכים יותר ממה שציפיתם — חפשו codespaces שנשכחו פתוחים או machine types מנופחים.

4.9 Codespaces vs Local — מתי שווה ענן ומתי מקומי

אחרי כל מה שלמדנו, שאלה טבעית: האם כדאי לעבור ל-Codespaces לצמיתות? התשובה הקצרה: זה תלוי. Codespaces הוא כלי מצוין למקרים מסוימים, אבל הוא לא מחליף פיתוח מקומי בכל מצב. הגישה הנכונה לרוב המפתחים היא hybrid — פיתוח מקומי יומיומי, Codespaces למקרים ספציפיים שבהם הוא מנצח.

הנה המקרים שבהם כל גישה מנצחת:

חשוב לזכור: devcontainer.json שווה גם בלי Codespaces. אם כתבתם devcontainer.json טוב, כל מפתח בצוות יכול להשתמש בו מקומית עם VS Code Dev Containers extension ו-Docker Desktop. אותו קובץ, אותה סביבה — רק שהיא רצה על המחשב המקומי במקום בענן. ככה אתם מקבלים את יתרון העקביות (כולם על אותה סביבה) בלי עלויות הענן.

תרחיש אופטימלי לצוות: כולם משתמשים באותו devcontainer.json. מפתחים עם מחשבים חזקים עובדים מקומית עם Dev Containers. מפתחים עם מחשבים חלשים או שעובדים מרחוק — ב-Codespaces. חבר צוות חדש? Codespace מוכן תוך 15 שניות (עם prebuilds). PR review מורכב? Codespace על הבראנץ'. סדנה או הדגמה? Codespace לכל המשתתפים.

4.10 סיכום ומבט קדימה

בפרק הבא: נעבור מסביבת הפיתוח לניהול הפרויקט — עם GitHub Projects. תלמדו ליצור boards, שדות מותאמים, תצוגות, ואוטומציות שמנהלים את הפרויקט בלי מאמץ. ה-codespace שהגדרתם כאן ישמש אתכם לפיתוח שוטף מתוך ה-project board.