CLI ותהליך CI

כשהפרסום הופך לשגרה,
אפשר להריץ אותו מסקריפט

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

$npm install -g @deploypages/cli
הצג תיעודקבל גישה לפרסום
💻
בנייה מקומית
zsh
➜ app git:(main) deploy ./dist
ℹ Deploying to my-app
ℹ Uploading... 100%
✔ Success!
☁️
פרסום קבוע

למהדורות שמריצים יותר מפעם אחת

מפסיקים להסתמך על זיכרון ידני

פקודת פרסום הופכת העלאה חוזרת לשלב שחרור שהצוות יכול לתעד, לסקור ולהריץ באותו אופן.

נותנים ל-CI לסיים את העבודה

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

שומרים על אותו מודל פרויקט

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

קודם ידני, אוטומציה כשהיא באמת נחוצה

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

steps:
  - uses: actions/checkout@v2
  - run: npm install && npm run build
  - run: npx @deploypages/cli deploy ./dist --token ${{ secrets.DEPLOY_TOKEN }}

שאלות נפוצות

Q: האם זה יכול לפעול ב-Windows, macOS ו-Linux?

כן. נתיב פרסום שימושי דרך CLI צריך להתאים למערכות ההפעלה שהצוות כבר משתמש בהן לבנייה מקומית ול-CI runners.

Q: האם אני יכול למקד לפרויקט ספציפי מתוך אוטומציה?

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

Q: האם זה מתאים ל-monorepo?

כן. צוותים עם monorepos צריכים נתיב פרסום שיכול למקד תיקיות עבודה ספציפיות ולפרסם פלטים בצורה נקייה.

מתחילים מהחלק שכבר יש לכל אתר סטטי

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