כיצד להקים צינור CI/CD עם TeamCity ו-Kotlin DSL

מדריך מלא: צינור CI/CD עם TeamCity ו-Kotlin DSL

תארו לעצמכם: חנות מקוונת ב-Node.js עם שלוש סביבות (dev, staging, production). כל build מאפס, תלויות נמשכות מ-npm ללא מטמון, בדיקות רצות ברצף. הפריסה ארכה 40 דקות, וחזרה לגרסה קודמת משמעותה העלאה ידנית של ארכיון דרך SSH. לאחר ביקורת, הגדרנו TeamCity: שלבים מקבילים, שמירת מטמון node_modules, בדיקות אוטומטיות בקונטיינרים. זמן ה-build ירד ל-8 דקות — פי 5 מהר יותר. מפתחים הפסיקו לחכות, ושחרורים הפכו ליומיים. חיסכון בזמן זה מוריד ישירות את עלות הבעלות הכוללת (TCO) ומאיץ את הגעת התכונות לייצור. הצוות שלנו עם ניסיון של 10 שנים יקים CI/CD במפתח מלא: מהתקנת שרת ועד תיעוד. עלות ההתקנה מתחילה ב-$2,000 לצינור בסיסי, עם חיסכון פוטנציאלי של $4,000 בחודש בזמן מפתחים — כלומר $48,000 בשנה.

אתגרים טכניים אופייניים

שאילתות N+1 בבדיקות — TeamCity אוסף דוחות כיסוי ומוצא צווארי בקבוק בשלב ה-CI. סביבות מלוכלכות — כל build על סוכן Docker נקי, קונפליקטים מבוטלים. Builds איטיים — שלבים מקבילים ושמירת מטמון תלויות (npm cache, Maven local) מקצרים זמן עד 70%. לפרויקט Node.js טיפוסי, build עם מטמון לוקח 2–3 דקות במקום 10. זמן ההתאוששות הממוצע (MTTR) יורד ל-15 דקות בזכות חזרות אוטומטיות לגרסה קודמת. הגדרת CI/CD עם TeamCity מהירה פי 2 מ-Jenkins ל-builds מקבילים.

הגדרת צינור: Kotlin DSL ושלבים

אנו משתמשים ב-Kotlin DSL — תצורה כקוד, מנוהלת בגיט וכפופה לבדיקת קוד. לפי JetBrains, Kotlin DSL מספק בטיחות טיפוסים והשלמת קוד אוטומטית ב-IDE לתצורות build. TeamCity תומך בצינורות מורכבים עם שלבים מקבילים. להלן צינור טיפוסי ליישום Node.js:

// .teamcity/settings.kts
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.*
import jetbrains.buildServer.configs.kotlin.triggers.*

version = "latest"

project {
    buildType(Build)
    buildType(Test)
    buildType(Deploy)
    buildTypesOrder = arrayListOf(Build, Test, Deploy)
}

object Build : BuildType({
    name = "Build"
    vcs {
        root(DslContext.settingsRoot)
    }
    steps {
        nodeJS {
            shellScript = "npm ci && npm run build"
        }
    }
    artifactRules = "dist/** => dist.zip"
})

object Test : BuildType({
    name = "Test"
    dependencies {
        snapshot(Build) {}
    }
    steps {
        script {
            scriptContent = """
                npm ci
                npm test -- --coverage --ci
            """.trimIndent()
        }
    }
    failureConditions {
        testFailure = true
        errorMessage = true
    }
})

object Deploy : BuildType({
    name = "Deploy to Production"
    type = Type.DEPLOYMENT
    dependencies {
        snapshot(Test) {}
        artifacts(Build) {
            artifactRules = "dist.zip => ."
        }
    }
    params {
        param("deploy.env", "production")
    }
    steps {
        script {
            scriptContent = """
                unzip dist.zip -d /var/www/app/
                sudo systemctl reload nginx
            """.trimIndent()
        }
    }
    triggers {
        vcs {
            branchFilter = "+:refs/heads/main"
        }
    }
})

פריסה דרך SSH

לפרויקטי PHP (Laravel, Symfony), הוספנו שלב SSH:

sshExec {
    commands = """
        cd /var/www/app
        git pull origin main
        composer install --no-dev --optimize-autoloader
        php artisan migrate --force
        php artisan config:cache
        php artisan route:cache
        php artisan view:cache
        sudo systemctl reload php8.3-fpm
    """.trimIndent()
    targetUrl = "deploy-server.example.com"
    authMethod = uploadedKey {
        username = "deploy"
        key = "deploy_key"
    }
}

Docker Build ב-TeamCity

קונטיינריזציה מאחדת את הסביבה ומבטלת שגיאות מסוג "עובד אצלי במחשב".

steps {
  dockerCommand {
    commandType = build {
      source = file {
        path = "Dockerfile"
      }
      namesAndTags = "registry.example.com/myapp:%build.counter%"
      commandArgs = "--no-cache"
    }
  }
  dockerCommand {
    commandType = push {
      namesAndTags = "registry.example.com/myapp:%build.counter%"
    }
  }
}

פרמטרים ותבניות

פרויקטים מרובי סביבות (staging, production) מוגדרים דרך תבניות. תבנית אחת — שלוש סביבות, מינימום קוד.

template("DeployTemplate") {
    params {
        param("env.name", "")
        param("env.url", "")
        param("ssh.host", "")
    }
    steps {
        script {
            scriptContent = "deploy.sh %env.name% %env.url%"
        }
    }
}

object DeployStaging : BuildType({
    templates(DeployTemplate)
    params {
        param("env.name", "staging")
        param("env.url", "https://staging.example.com")
        param("ssh.host", "staging.server.com")
    }
})

למה TeamCity עדיף על Jenkins?

TeamCity מהיר יותר עם builds מקבילים — פי 2, בזכות אחסון artifacts מובנה ותזמון חכם. Kotlin DSL מציע בטיחות טיפוסים והשלמת קוד אוטומטית ב-IDE, בעוד Jenkins Pipeline משתמש ב-Groovy עם טיפוסים דינמיים, מה שמוביל לעיתים קרובות לשגיאות ריצה. תבניות מובנות ופרמטרי סביבה ב-TeamCity מפשטים קנה מידה לעשרות פרויקטים. להבהרה:

הזמינו הגדרת TeamCity וקבלו צינור מוכן עם תיעוד תוך 5–7 ימים. תהליך הגדרת CI/CD עם TeamCity פשוט ויכול לחסוך לצוות שלכם 30–40 שעות בחודש.

איך להגדיר TeamCity CI/CD ב-5 שלבים

1. התקינו שרת TeamCity וסוכנים — השתמשו ב-Docker או בשרת פיזי. הרכיבו volumes לנתונים וללוגים.
2. הגדירו VCS roots — התחברו למאגר Git והגדירו VCS triggers.
3. הגדירו תצורות build — כתבו סקריפטים ב-Kotlin DSL לשלבי build, בדיקה ופריסה.
4. הגדירו תבניות סביבה — צרו תבניות עם פרמטרים ל-dev, staging ו-production.
5. הפעילו התראות ותיעוד — הגדירו התראות Slack/אימייל ותעדו את הצינור.

פריסה למספר סביבות מוגדרת באמצעות תבניות עם פרמטרים. כל סביבה היא סוג build נפרד המקושר לתבנית. VCS triggers על main מריצים פריסה אוטומטית ל-staging; production רק דרך trigger ידני בממשק. זה מונע פריסות ייצור מקריות.

אילו פרויקטים דורשים אוטומציית CI/CD?

כל פרויקט שבו שחרורים מתרחשים יותר מפעם בחודש והפריסה ידנית. במיוחד אם הצוות מונה יותר משני מפתחים. TeamCity מחזיר את ההשקעה על ידי הפחתת זמן build וביטול שגיאות אנוש. הלקוחות שלנו — מסטארטאפים פינטק ועד פורטלים ארגוניים — חוסכים 10 עד 40 שעות בחודש בפעולות פריסה.

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

• ביקורת תהליך build ופריסה נוכחי (יום אחד)
• התקנת שרת TeamCity וסוכנים (Docker או שרת פיזי) — יום אחד
• VCS triggers, תצורת build, בדיקות ו-artifacts
• תבניות סביבה (dev/staging/production)
• התראות סטטוס build (Slack, אימייל)
• בדיקת צינור ותיקון באגים
• תיעוד והדרכה לצוות שלכם
• אחריות לחודש לאחר המסירה

לוחות זמנים ועלות

העלות מחושבת באופן אישי לאחר ניתוח הפרויקט. לוחות זמנים משוערים:

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