# გენერირებული Xcode პროექტი {#generated-xcode-project}

::: code-group

```text [Agent prompt]
Help me get started with Tuist. Follow the setup at:
https://tuist.dev/en/docs/guides/get-started/generated-xcode-project
```

:::

მიჰყევით ამ გზას, როდესაც გსურთ, რომ Tuist-მა აღწეროს და შექმნას თქვენი Xcode პროექტი Swift მანიფესტებიდან. გენერირებული პროექტი კომპაქტურად აჯამებს მოდულური Xcode პროექტის სირთულეს გრაფის მოკლე, დეკლარატიულ აღწერაში. ის ასევე მკაცრი წინაპირობაა მოდულის ქეშისა და შერჩევითი ტესტირებისთვის.

ქვემოთ მოცემული თითოეული განყოფილება იწყება იმის აღწერით, რაც დღეს აკლია, შემდეგ კი გაჩვენებთ ფუნქციას, რომელიც ამ ნაკლოვანებას ავსებს.

## წინაპირობები

- macOS ინსტალირებული Xcode-ით.
- <.localized_link href="/guides/install-tuist">Tuist ბრძანების ხაზის ინტერფეისი</.localized_link>.

## პროექტის შექმნა

მუშაობის სანახავად ყველაზე სწრაფი გზა ახალი პროექტია. ცარიელ დირექტორიაში გაუშვით `tuist init` და აირჩიეთ **გენერირებული პროექტის შექმნა**, მიუთითეთ პლატფორმა, დაადასტურეთ სახელი, შემდეგ გაიარეთ ავტორიზაცია და აირჩიეთ ანგარიში, რომელსაც უნდა ეკუთვნოდეს პროექტი.

```bash
mkdir MyApp && cd MyApp
tuist init
```

თუ ამას კოდირების აგენტით ან სკრიპტით აკეთებთ, ჯერ გაუშვით `tuist auth login` (ბრაუზერის ნაკადი ელოდება Enter-ზე დაჭერას), შემდეგ გამოიყენეთ არაინტერაქტიული ფორმა:

```bash
tuist init --build-system generated-xcode --name MyApp --platform ios --account <account>
```

init-ის დასრულების შემდეგ გაუშვით `tuist generate`. Tuist ქმნის `.xcworkspace` თქვენს მანიფესტებთან ერთად და ხსნის მას Xcode-ში. ააწყვეთ და გაუშვით სამიზნე. სიმულატორში უნდა დაინახოთ მაგალითის აპლიკაციის გაშვება.

ეს არის „დაკავშირებული + გენერირების“ მდგომარეობა. ქვემოთ მოცემული ყველაფერი არის სურვილისამებრ და დამოუკიდებელი.

თუ არსებულ აპლიკაციას გადაიტანთ, ჯერ დააკავშირეთ ის [Xcode პროექტის მიგრაციის სახელმძღვანელოს](https://tuist.dev/en/docs/guides/features/projects/adoption/migrate/xcode-project) მიხედვით, შემდეგ დაბრუნდით და გააგრძელეთ იმ განყოფილებებით, რომლებიც თქვენს პრობლემას შეესაბამება.

## პროექტის გენერაცია

`.xcodeproj` აჯამებს თქვენი აპლიკაციის სტრუქტურას XML-ში: ფაილის მითითებები, აწყობის ეტაპები, სამიზნე დამოკიდებულებები, სქემები და აწყობის პარამეტრები ყველა ერთ ხეშია განთავსებული, გრაფის, როგორც გრაფის ანალიზისთვის საჭირო პრიმიტივის გარეშე. პროექტის ზრდასთან ერთად, ამ სტრუქტურის თავში დაჭერა რთულდება და Xcode-ს არ აქვს სტაბილური სახელური იმისთვის, რომ ინსტრუმენტებმა მისი ჰეშირება მოახდინონ და გამოტოვონ სამუშაო, როცა არაფერი შეცვლილა.

გენერირებული პროექტები გრაფს კომპაქტურად აჯამებენ დეკლარატიულ Swift-ში. `Project.swift` პირდაპირ აღწერს სამიზნეებს, დამოკიდებულებებს და რესურსებს, ხოლო Tuist ინარჩუნებს მის უკან მდგომი გრაფის სტაბილურ მოდელს. სწორედ ეს მოდელი ხსნის ქვემოთ მოცემულ განყოფილებებს: მოდულის ქეშირება ახდენს მის ჰეშირებას ბინარების ხელახლა გამოსაყენებლად, ხოლო შერჩევითი ტესტირება ახდენს მის ჰეშირებას იმ ტესტების გამოტოვებისთვის, რომელთა შესავალი მონაცემები არ შეცვლილა.

```swift
import ProjectDescription

let project = Project(
    name: "MyApp",
    targets: [
        .target(
            name: "MyApp",
            destinations: .iOS,
            product: .app,
            bundleId: "dev.tuist.MyApp",
            sources: ["MyApp/Sources/**"],
            dependencies: []
        )
    ]
)
```

თითოეული `tuist generate` ქმნის დეტერმინისტულ სამუშაო სივრცეს მანიფესტებიდან. დაამატეთ `.xcodeproj` და `.xcworkspace` `.gitignore`-ში.

## მოდულის ქეში

მოდულური Xcode პროექტის ნულიდან კომპილაცია თითოეული მანქანისთვის ხარჯია. თითოეული თანამშრომელი და თითოეული CI გამშვები ქმნის იგივე ობიექტური ფაილების საკუთარ ასლს. Xcode კომპილაციის ქეში ამცირებს შიდა ციკლს, მაგრამ არ აშორებს თითოეული სამიზნის თითოეულ მანქანაზე აწყობას და ვერ ცვლის მთელ ფრეიმვორკს წინასწარ აწყობილი ბინარით.

მოდულის ქეში ამას აკეთებს. ის ერთხელ აწყობს თქვენს გრაფში არსებულ ყველა ქეშირებად დამოკიდებულებას (ფრეიმვორკები, ბიბლიოთეკები, ბანდლები), ინახავს მიღებულ ბინარებს სამიზნის შესავალი მონაცემების ჰეშის მიხედვით და მომდევნო გენერაციებზე ცვლის სამიზნეს მისი ბინარით. შეუცვლელი მოდულები აღარ კომპილდება:

```bash
tuist cache
```

პირველი გაშვება ყველაფერს აკომპილირებს და ატვირთავს ბინარებს თქვენს ანგარიშზე. შემდეგ `tuist generate`-ზე შეუცვლელი დამოკიდებულებები ჩანაცვლდება მათი ქეშირებული ბინარებით და Xcode აკავშირებს `.xcframework`-ებს წყაროდან კომპილაციის ნაცვლად.

## შერჩევითი ტესტირება

`xcodebuild test` არ იცის, რომელ ტესტებს ეხება ცვლილება, ამიტომ CI ყოველ push-ზე მთელ სუიტს აწარმოებს. სუიტის ზრდასთან ერთად, სხვაობა იმას შორის, რაც რეალურად უნდა გაეშვას და იმას შორის, რაც ეშვება, იზრდება წუთებიდან ათეულობით წუთამდე.

შერჩევითი ტესტირება აწარმოებს მხოლოდ იმ ტესტებს, რომლებზეც იმოქმედა ბოლო წარმატებული ტესტების გაშვების შემდეგ მომხდარმა ცვლილებებმა, პროექტის გრაფისა და იმავე ჰეშირების ალგორითმის გამოყენებით, რომელსაც მოდულის ქეში ეყრდნობა:

```bash
tuist test
```

პირველი `tuist test` აწარმოებს ყველაფერს და ინახავს თითოეული სამიზნის ჰეშებს. მომდევნო გაშვებები ტოვებენ სამიზნეებს, რომელთა შესავალი მონაცემები არ შეცვლილა. გადაიტანეთ `tuist test` CI-ში `xcodebuild test`-ის ნაცვლად და უკუკავშირი წუთების ნაცვლად წამებში მოვა.

## პაკეტების რეესტრი

Swift Package Manager აგვარებს დამოკიდებულებებს თითოეული პაკეტის git ისტორიის სრული კლონირებით, რადგან პაკეტები მიმართულია URL-ით და არა რეესტრით. ათეულობით ტრანზიტული პაკეტის მქონე პროექტზე, აგვარება სუფთა checkout-ზე წუთებს მოითხოვს და მეორდება ყოველ CI სამუშაოზე.

Tuist Package Registry ემსახურება იმავე პაკეტებს, რომლებსაც Swift Package Index აკონტროლებს, მაგრამ როგორც რეალური რეესტრი, რათა SwiftPM-მა მიიღოს მხოლოდ ის კომიტი, რომელიც რეალურად გჭირდებათ. ჩართეთ ის ერთხელ `registryEnabled: true`-ის დაყენებით თქვენს `Tuist.swift`-ში:

```swift
let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(
            registryEnabled: true
        )
    )
)
```

ხელახლა გენერირება. პაკეტების აგვარება წუთებიდან წამებამდე ეცემა.

## აწყობის ინსაითები

Xcode იწერს თითოეული სამიზნის აწყობის ხანგრძლივობას ჟურნალში და აწყობის ანგარიშში. არცერთი არ არის აგრეგირებული გაშვებებსა თუ მანქანებს შორის, ამიტომ აწყობის დროის რეგრესია ჩვეულებრივ მხოლოდ CI-ის საერთო შენელებად ვლინდება.

Build insights ავტომატურად იწერს ყოველი აწყობის ხანგრძლივობას და ფაზების დროს გენერირებული სქემებისთვის. დამატებითი კონფიგურაცია არ არის საჭირო. გახსენით დაშბორდის **აწყობები** ჩანართი თქვენი შემდეგი `tuist generate` + აწყობის ციკლის შემდეგ.

## ტესტების ინსაითები

Xcode ანგარიშობს თითოეული ტესტის შედეგებს ერთი გაშვებით ერთდროულად. ის არ აჯამებს გაშვებებს შორის არსებულ სიგნალს, რომელიც რეალურად გჭირდებათ: არასტაბილურობის მაჩვენებელი, კვირიდან კვირამდე ხანგრძლივობა, რომელი სიმულატორის ვარიანტები მარცხდება.

Test insights ავტომატურად იწერს ყოველი ტესტის შედეგს და ხანგრძლივობას გენერირებული სქემებისთვის და აკორელირებს შედეგებს გაშვებებს შორის. არასტაბილური ტესტები, ნელი ტესტები და შეცდომები ჩანსახავს დაშბორდის **ტესტები** ჩანართზე. როცა არასტაბილურობა გროვდება, იზოლირეთ ისინი დაშბორდიდან, რათა შეწყვიტონ შერწყმების ბლოკირება.

## გუნდის ჩართვა

მოდულის ქეში და შერჩევითი ტესტირება ყველაზე მეტად მაშინ იძლევა შედეგს, როცა ყველა ერთსა და იმავე საერთო ზედაპირს ეხება. მიიწვიეთ თქვენი თანაგუნდელები ორგანიზაციაში დაშბორდის ანგარიშის პარამეტრებიდან და დააყენეთ <.localized_link href="/guides/integrations/authentication/sso">ერთიანი შესვლა</.localized_link> (Google, Okta, Microsoft), რათა დარეგისტრირება იყოს ერთი დაწკაპუნება და არა თითოეული პირისთვის `tuist auth login`.

გენერირებული Xcode პროექტი

plaintext

Help me get started with Tuist. Follow the setup at:
https://tuist.dev/en/docs/guides/get-started/generated-xcode-project

მიჰყევით ამ გზას, როდესაც გსურთ, რომ Tuist-მა აღწეროს და შექმნას თქვენი Xcode პროექტი Swift მანიფესტებიდან. გენერირებული პროექტი კომპაქტურად აჯამებს მოდულური Xcode პროექტის სირთულეს გრაფის მოკლე, დეკლარატიულ აღწერაში. ის ასევე მკაცრი წინაპირობაა მოდულის ქეშისა და შერჩევითი ტესტირებისთვის.

ქვემოთ მოცემული თითოეული განყოფილება იწყება იმის აღწერით, რაც დღეს აკლია, შემდეგ კი გაჩვენებთ ფუნქციას, რომელიც ამ ნაკლოვანებას ავსებს.

წინაპირობები#

macOS ინსტალირებული Xcode-ით.
Tuist ბრძანების ხაზის ინტერფეისი.

პროექტის შექმნა#

მუშაობის სანახავად ყველაზე სწრაფი გზა ახალი პროექტია. ცარიელ დირექტორიაში გაუშვით tuist init და აირჩიეთ გენერირებული პროექტის შექმნა, მიუთითეთ პლატფორმა, დაადასტურეთ სახელი, შემდეგ გაიარეთ ავტორიზაცია და აირჩიეთ ანგარიში, რომელსაც უნდა ეკუთვნოდეს პროექტი.

bash

mkdir MyApp && cd MyApp
tuist init

თუ ამას კოდირების აგენტით ან სკრიპტით აკეთებთ, ჯერ გაუშვით tuist auth login (ბრაუზერის ნაკადი ელოდება Enter-ზე დაჭერას), შემდეგ გამოიყენეთ არაინტერაქტიული ფორმა:

bash

tuist init --build-system generated-xcode --name MyApp --platform ios --account <account>

init-ის დასრულების შემდეგ გაუშვით tuist generate. Tuist ქმნის .xcworkspace თქვენს მანიფესტებთან ერთად და ხსნის მას Xcode-ში. ააწყვეთ და გაუშვით სამიზნე. სიმულატორში უნდა დაინახოთ მაგალითის აპლიკაციის გაშვება.

ეს არის „დაკავშირებული + გენერირების“ მდგომარეობა. ქვემოთ მოცემული ყველაფერი არის სურვილისამებრ და დამოუკიდებელი.

თუ არსებულ აპლიკაციას გადაიტანთ, ჯერ დააკავშირეთ ის Xcode პროექტის მიგრაციის სახელმძღვანელოს მიხედვით, შემდეგ დაბრუნდით და გააგრძელეთ იმ განყოფილებებით, რომლებიც თქვენს პრობლემას შეესაბამება.

პროექტის გენერაცია#

.xcodeproj აჯამებს თქვენი აპლიკაციის სტრუქტურას XML-ში: ფაილის მითითებები, აწყობის ეტაპები, სამიზნე დამოკიდებულებები, სქემები და აწყობის პარამეტრები ყველა ერთ ხეშია განთავსებული, გრაფის, როგორც გრაფის ანალიზისთვის საჭირო პრიმიტივის გარეშე. პროექტის ზრდასთან ერთად, ამ სტრუქტურის თავში დაჭერა რთულდება და Xcode-ს არ აქვს სტაბილური სახელური იმისთვის, რომ ინსტრუმენტებმა მისი ჰეშირება მოახდინონ და გამოტოვონ სამუშაო, როცა არაფერი შეცვლილა.

გენერირებული პროექტები გრაფს კომპაქტურად აჯამებენ დეკლარატიულ Swift-ში. Project.swift პირდაპირ აღწერს სამიზნეებს, დამოკიდებულებებს და რესურსებს, ხოლო Tuist ინარჩუნებს მის უკან მდგომი გრაფის სტაბილურ მოდელს. სწორედ ეს მოდელი ხსნის ქვემოთ მოცემულ განყოფილებებს: მოდულის ქეშირება ახდენს მის ჰეშირებას ბინარების ხელახლა გამოსაყენებლად, ხოლო შერჩევითი ტესტირება ახდენს მის ჰეშირებას იმ ტესტების გამოტოვებისთვის, რომელთა შესავალი მონაცემები არ შეცვლილა.

swift

import ProjectDescription

let project = Project(
    name: "MyApp",
    targets: [
        .target(
            name: "MyApp",
            destinations: .iOS,
            product: .app,
            bundleId: "dev.tuist.MyApp",
            sources: ["MyApp/Sources/**"],
            dependencies: []
        )
    ]
)

თითოეული tuist generate ქმნის დეტერმინისტულ სამუშაო სივრცეს მანიფესტებიდან. დაამატეთ .xcodeproj და .xcworkspace.gitignore-ში.

მოდულის ქეში#

მოდულური Xcode პროექტის ნულიდან კომპილაცია თითოეული მანქანისთვის ხარჯია. თითოეული თანამშრომელი და თითოეული CI გამშვები ქმნის იგივე ობიექტური ფაილების საკუთარ ასლს. Xcode კომპილაციის ქეში ამცირებს შიდა ციკლს, მაგრამ არ აშორებს თითოეული სამიზნის თითოეულ მანქანაზე აწყობას და ვერ ცვლის მთელ ფრეიმვორკს წინასწარ აწყობილი ბინარით.

მოდულის ქეში ამას აკეთებს. ის ერთხელ აწყობს თქვენს გრაფში არსებულ ყველა ქეშირებად დამოკიდებულებას (ფრეიმვორკები, ბიბლიოთეკები, ბანდლები), ინახავს მიღებულ ბინარებს სამიზნის შესავალი მონაცემების ჰეშის მიხედვით და მომდევნო გენერაციებზე ცვლის სამიზნეს მისი ბინარით. შეუცვლელი მოდულები აღარ კომპილდება:

bash

tuist cache

პირველი გაშვება ყველაფერს აკომპილირებს და ატვირთავს ბინარებს თქვენს ანგარიშზე. შემდეგ tuist generate-ზე შეუცვლელი დამოკიდებულებები ჩანაცვლდება მათი ქეშირებული ბინარებით და Xcode აკავშირებს .xcframework-ებს წყაროდან კომპილაციის ნაცვლად.

შერჩევითი ტესტირება#

xcodebuild test არ იცის, რომელ ტესტებს ეხება ცვლილება, ამიტომ CI ყოველ push-ზე მთელ სუიტს აწარმოებს. სუიტის ზრდასთან ერთად, სხვაობა იმას შორის, რაც რეალურად უნდა გაეშვას და იმას შორის, რაც ეშვება, იზრდება წუთებიდან ათეულობით წუთამდე.

შერჩევითი ტესტირება აწარმოებს მხოლოდ იმ ტესტებს, რომლებზეც იმოქმედა ბოლო წარმატებული ტესტების გაშვების შემდეგ მომხდარმა ცვლილებებმა, პროექტის გრაფისა და იმავე ჰეშირების ალგორითმის გამოყენებით, რომელსაც მოდულის ქეში ეყრდნობა:

bash

tuist test

პირველი tuist test აწარმოებს ყველაფერს და ინახავს თითოეული სამიზნის ჰეშებს. მომდევნო გაშვებები ტოვებენ სამიზნეებს, რომელთა შესავალი მონაცემები არ შეცვლილა. გადაიტანეთ tuist test CI-ში xcodebuild test-ის ნაცვლად და უკუკავშირი წუთების ნაცვლად წამებში მოვა.

პაკეტების რეესტრი#

Swift Package Manager აგვარებს დამოკიდებულებებს თითოეული პაკეტის git ისტორიის სრული კლონირებით, რადგან პაკეტები მიმართულია URL-ით და არა რეესტრით. ათეულობით ტრანზიტული პაკეტის მქონე პროექტზე, აგვარება სუფთა checkout-ზე წუთებს მოითხოვს და მეორდება ყოველ CI სამუშაოზე.

Tuist Package Registry ემსახურება იმავე პაკეტებს, რომლებსაც Swift Package Index აკონტროლებს, მაგრამ როგორც რეალური რეესტრი, რათა SwiftPM-მა მიიღოს მხოლოდ ის კომიტი, რომელიც რეალურად გჭირდებათ. ჩართეთ ის ერთხელ registryEnabled: true-ის დაყენებით თქვენს Tuist.swift-ში:

swift

let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(
            registryEnabled: true
        )
    )
)

ხელახლა გენერირება. პაკეტების აგვარება წუთებიდან წამებამდე ეცემა.

აწყობის ინსაითები#

Xcode იწერს თითოეული სამიზნის აწყობის ხანგრძლივობას ჟურნალში და აწყობის ანგარიშში. არცერთი არ არის აგრეგირებული გაშვებებსა თუ მანქანებს შორის, ამიტომ აწყობის დროის რეგრესია ჩვეულებრივ მხოლოდ CI-ის საერთო შენელებად ვლინდება.

Build insights ავტომატურად იწერს ყოველი აწყობის ხანგრძლივობას და ფაზების დროს გენერირებული სქემებისთვის. დამატებითი კონფიგურაცია არ არის საჭირო. გახსენით დაშბორდის აწყობები ჩანართი თქვენი შემდეგი tuist generate + აწყობის ციკლის შემდეგ.

ტესტების ინსაითები#

Xcode ანგარიშობს თითოეული ტესტის შედეგებს ერთი გაშვებით ერთდროულად. ის არ აჯამებს გაშვებებს შორის არსებულ სიგნალს, რომელიც რეალურად გჭირდებათ: არასტაბილურობის მაჩვენებელი, კვირიდან კვირამდე ხანგრძლივობა, რომელი სიმულატორის ვარიანტები მარცხდება.

Test insights ავტომატურად იწერს ყოველი ტესტის შედეგს და ხანგრძლივობას გენერირებული სქემებისთვის და აკორელირებს შედეგებს გაშვებებს შორის. არასტაბილური ტესტები, ნელი ტესტები და შეცდომები ჩანსახავს დაშბორდის ტესტები ჩანართზე. როცა არასტაბილურობა გროვდება, იზოლირეთ ისინი დაშბორდიდან, რათა შეწყვიტონ შერწყმების ბლოკირება.

გუნდის ჩართვა#

მოდულის ქეში და შერჩევითი ტესტირება ყველაზე მეტად მაშინ იძლევა შედეგს, როცა ყველა ერთსა და იმავე საერთო ზედაპირს ეხება. მიიწვიეთ თქვენი თანაგუნდელები ორგანიზაციაში დაშბორდის ანგარიშის პარამეტრებიდან და დააყენეთ ერთიანი შესვლა (Google, Okta, Microsoft), რათა დარეგისტრირება იყოს ერთი დაწკაპუნება და არა თითოეული პირისთვის tuist auth login.