CI/CD עבור .NET: MSBuild ו-dotnet CLI בפועל

CI/CD עבור .NET: MSBuild ו-dotnet CLI בפועל

תארו לעצמכם: אתם משחררים גרסה חדשה של אפליקציית .NET, והפיימליין נכשל ב-dotnet restore כי לסוכן אין קאש — ואתם צריכים לחכות 5 דקות רק כדי להוריד תלויות. או שכל הצוות מחכה בזמן שג'נקינס בונה פרויקט legacy של ASP.NET Framework דרך msbuild.exe על סוכן Windows, ואז מישהו מבצע דיפלוי ידני ל-IIS. נשמע מוכר? נתקלנו במצבים האלה פעמים רבות: גם עם .NET Framework legacy וגם עם .NET מודרני (החל מגרסה 6) באמצעות dotnet publish ובניית Docker רב-שלבית. הערימה שונה — וגם הגישות לפיימליין. הקמנו CI/CD turnkey עבור כל פרויקט .NET, מאיצים שחרורים ומפחיתים פעולות ידניות. צרו קשר כדי להעריך את הפרויקט שלכם ולקבל פתרון.

קאש של חבילות NuGet עבור מערכות הפעלה שונות

ללא קאש, dotnet restore על סוכן נקי מושך תלויות מאפס — 2–5 דקות רק עבור restore. ב-GitHub Actions, הגדרת קאש לחבילות נעשית כך:

---
- uses: actions/cache@v4
  with:
    path: ~/.nuget/packages
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj', '**/*.props') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

עבור runner עצמי ב-Windows, הנתיב הוא - uses: actions/cache@v4 with: path: ~/.nuget/packages key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj', '**/*.props') }} restore-keys: | ${{ runner.os }}-nuget- . אם לא מתחשבים בזה בקונפיג, הקאש לא יחול. עם קאש, restore לוקח שניות במקום דקות. קאש NuGet הוא אחד מהאופטימיזציות המרכזיות של הפיימליין. למידע נוסף על NuGet.

למה בניית .NET Framework דורשת סוכן Windows?

תלויות ייחודיות ל-Windows: רכיבי COM, רישום Windows, קריאות P/Invoke legacy — קוד כזה לא ניתן לבנות על סוכן Linux. פתרון: או להשאיר סוכן Windows לבנייה, או לבצע רפקטורינג לקוד (לא תמיד אפשרי). MSBuild על Windows דרך %USERPROFILE%\.nuget\packages הוא לפעמים האפשרות היחידה. הגדרת הסוכן לכל תלות היא משימה סטנדרטית.

מיגרציות EF Core ב-CI

טעות אופיינית: מיגרציות מוחלות ישירות על מסד הנתונים מהפיימליין עם msbuild /p:Configuration=Release /p:Platform="Any CPU" ללא בדיקת idempotency. בפריסות staging מקבילות, שני פודים מנסים להחיל את אותה מיגרציה בו-זמנית — race condition. במקום זאת, צרו סקריפט מיגרציה SQL (dotnet ef database update) והחילו אותו דרך init-container או שלב נפרד עם נעילה מפורשת. Microsoft Docs: מיגרציות EF Core.

חתימה על ארטיפקטים ופרסום חבילות NuGet

אם הפרויקט הוא ספרייה, הפיימליין צריך לפרסם חבילה ל-Nexus או Azure Artifacts רק על תג release. ניואנס: dotnet ef migrations script --idempotent ו-dotnet pack דורשים מפתח API, שאסור שיהיה hardcoded. השתמשו ב-GitHub secrets או Vault, ובתנאי כמו dotnet nuget push.

GitHub Actions או GitLab CI עבור .NET?

שני הכלים טובים, אבל GitHub Actions מנצח באינטגרציה עם אקוסיסטם .NET: קאש מובנה, marketplace עם actions עבור SonarQube ו-Codecov, YAML פשוט. GitLab CI דורש runner משלו אבל נותן יותר שליטה על instances. מבחינת עלות: GitHub Actions חינמי עבור מאגרים ציבוריים; GitLab CI חינמי עד 400 דקות בחודש. בפועל, אנחנו משתמשים ב-GitHub Actions עבור .NET לרוב (75% מהפרויקטים) כי זה דורש פחות קונפיגורציה.

פיימליין .NET טיפוסי: מודרני ו-legacy

עבור .NET מודרני (6+) על סוכן Linux

---
name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.x'
      - uses: actions/cache@v4
        with:
          path: ~/.nuget/packages
          key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage"
      - uses: codecov/codecov-action@v4

עבור .NET Framework על סוכן Windows

- name: Build run: msbuild MyApp.sln /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile 

SonarQube בפיימליין .NET

טעות נפוצה: הרצת if: startsWith(github.ref, 'refs/tags/') ללא name: CI on: [push, pull_request] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-dotnet@v4 with: dotnet-version: '8.x' - uses: actions/cache@v4 with: path: ~/.nuget/packages key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }} - run: dotnet restore - run: dotnet build --no-restore -c Release - run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage" - uses: codecov/codecov-action@v4 מוצלח בגלל שלב מותנה — הניתוח נכשל בהעלאה. תמיד עטפו ב-job אחד ללא דילוג על שלבים. השתמשו ב-- name: Build run: msbuild MyApp.sln /p:Configuration=Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile , לאחר מכן end, ולאחר מכן begin.

תמונת Docker עבור ASP.NET Core

בנייה רב-שלבית מקטינה את התמונה הסופית מ-1.5 GB לכ-200 MB — פי 7.5 קטן יותר. זה מאיץ פריסה ומפחית את שטח התקיפה. דוגמה ל-Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore
COPY . .
RUN dotnet publish "MyApp/MyApp.csproj" -c Release -o /app/publish
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

ב-CI: dotnet-sonarscanner begin /k:"projectKey", סריקה עם Trivy (dotnet build), דחיפה ל-registry עם תג git sha. מיקרוסופט ממליצה על בנייה רב-שלבית עבור תמונות production. Microsoft Docs: .NET Docker.

השוואת גישות לקאש NuGet

מה כוללת העבודה

• בדיקת מצב נוכחי: גרסת .NET, סוג פרויקט, תלויות, סביבת פריסה.
• הגדרת פיימליין: בחירת סוכן, קאש NuGet, בנייה, בדיקות, כיסוי, בניית Docker, דחיפה, שלבי פריסה.
• אינטגרציה של מנתחים: SonarQube, Coverlet, סריקת אבטחה (Trivy, Snyk).
• פריסה לכל סביבה: IIS, Kubernetes, Azure App Service, bare metal.
• תיעוד: משתנים, סודות, הוראות להוספת פרויקטים חדשים.
• הדרכת צוות: איך להשתמש בפיימליין ולפרש תוצאות.

אנחנו מבטיחים יציבות פיימליין: SLO uptime של 99.9%, runbook לכל תרחיש כשל. צרו קשר לבדיקת הפרויקט שלכם.

שלבי העבודה

1. בדיקת מצב נוכחי: גרסת .NET, סוג פרויקט (web/ספרייה/שירות), סקריפטי בנייה קיימים, תלויות (Windows-only או cross-platform), סביבת פריסה יעד.
2. עיצוב פיימליין: בחירת סוכן, הגדרת קאש, שלבים: בנייה → בדיקות → כיסוי → בניית Docker → דחיפה → פריסה.
3. יישום: כתיבת YAML, Dockerfile, סקריפטים, אינטגרציה של מנתחים.
4. בדיקות: אימות על staging, בדיקת פריסות מקבילות, rollback.
5. פריסה ל-production ומתן תיעוד.

הערכות זמן

הזמינו הגדרת CI/CD turnkey עבור .NET. המהנדסים שלנו עם שנים של ניסיון ייקחו את הפרויקט שלכם מבדיקה ועד פריסה. קבלו ייעוץ — פשוט צרו קשר.