Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Çoğu CI sisteminde bulabileceğiniz bazı özellikler aşağıda verilmiştir.
Çevre
Sistemin iş akışını yürüttüğü donanım ve yazılım ortamını seçmek ve anlamak önemlidir. Android uygulamaları için dikkat edilmesi gereken önemli noktalar şunlardır:
Platform: Linux, Mac, Windows ve sürümleri.
Kullanılabilir bellek: Uygulama derlemek ve emülatör çalıştırmak çok fazla RAM kullanabilir ve bellek yetersizliği hatalarını önlemek için JVM'nin yığın boyutu gibi parametrelerde ince ayar yapılması genellikle gerekir.
Önceden yüklenmiş yazılımlar: CI sistemleri genellikle Java Geliştirme Kiti (JDK), Android Yazılım Geliştirme Kiti (SDK), derleme araçları, platformlar ve emülatörler gibi hâlihazırda mevcut olan geniş bir araç koleksiyonuyla görüntüler sağlar.
Çalıştırıcı mimarisi ve talimat grubu: ARM, x86. Emülatörleri kullanırken
bu önemlidir.
Ortam değişkenleri: Bazıları CI sistemi tarafından ayarlanır (örneğin: ANDROID_HOME) ve örneğin iş akışınıza kimlik bilgilerini gömmekten kaçınmak için kendi değerlerinizi ayarlayabilirsiniz.
Göz önünde bulundurmanız gereken başka pek çok konu vardır. Örneğin, kullanılabilir çekirdek sayısı ve sanallaştırmanın emülatörleri çalıştırmak için etkinleştirilip etkinleştirilmediği.
Günlükler ve raporlar
Bir adım başarısız olduğunda CI sistemi sizi bilgilendirir ve genellikle değişikliği birleştirmenize izin vermez. Nelerin yanlış gittiğini öğrenmek için günlüklerdeki hataları arayın.
Ayrıca, derleme ve test etme işlemleri sonucunda genellikle söz konusu yapının parçaları olarak depolanan raporlar oluşturulur. CI sistemine bağlı olarak, bu raporların sonuçlarını görselleştirmek için eklentileri kullanabilirsiniz.
Önbellek ve CI çalışma süreleri
CI sistemleri, işlemi hızlandırmak için derleme önbelleği kullanır. En basit haliyle, başarılı bir derlemenin ardından tüm Gradle önbellek dosyalarını kaydeder ve yeni bir derlemeden önce geri yükler. Bu, Gradle'ın derleme önbelleği özelliğine dayanır ve projenizde etkinleştirilmelidir.
Çalışma sürelerini ve güvenilirliği iyileştirmenin yollarından bazıları şunlardır:
Modüller: Bir değişiklikten hangi modüllerin etkilendiğini belirleme ve bunları yalnızca oluşturma ve test etme.
Parça testleri: Özellikle donanımlı testler; testleri birden fazla cihaz arasında parçalara ayırmak faydalı olabilir. Bu özellik Android çalıştırıcı, Gradle Managed Cihazlar ve Firebase Test Lab tarafından desteklenir.
Parça derlemeler: Derlemeyi birden fazla sunucu örneğine parçalayabilirsiniz.
Güvenilirlik, zaman zaman başarısız olan test veya araçları ifade eder. Her zaman, stabil olmayan derleme ve testlere neden olan sorunları bulup düzeltmeye çalışmanız gerekir. Ancak özellikle araçlı testleri çalıştırırken bunların yeniden oluşturulması zordur.
Yaygın olarak kullanılan bir strateji, başarısız olduklarında test çalıştırmalarını maksimum sayıda yeniden denemektir.
Yeniden denemeleri, birden çok düzeyde gerçekleşebileceği için yapılandırmanın tek bir yolu yoktur. Aşağıdaki tabloda, güvenilir olmayan bir test hatasına yanıt olarak gerçekleştirebileceğiniz işlemler özetlenmiştir:
Başarısız
İşlem
Emülatör bir saniye boyunca yanıt vermedi, zaman aşımı tetiklendi
Başarısız testi yeniden çalıştırma
Emülatör başlatılamadı
Tüm görevi yeniden çalıştırma
Kod ile ödeme aşamasında bağlantı hatası oluştu
İş akışını yeniden başlatma
Sistemin hangi bölümlerinin kaygan olduğunu günlüğe kaydedip izlemek; yalnızca yeniden denemelerle CI'nın güvenilir ve hızlı kalmasını sağlamaya yatırım yapmak önemlidir.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# CI features\n\nThe following are some features that you can find in most CI systems.\n\nEnvironment\n-----------\n\nIt's important to choose and understand the hardware and software environment in\nwhich the system executes the workflow. Important considerations for Android\napplications are:\n\n- **Platform**: Linux, Mac, Windows, and their versions.\n- **Available memory**: Building apps and running emulators can use a lot of RAM and it's often necessary to tweak parameters such as the JVM's heap size to avoid out-of-memory errors.\n- **Preinstalled software**: CI systems usually provide images with a large collection of tools already available, such as the Java Development Kit (JDK), the Android Software Development Kit (SDK), build tools, platforms and emulators.\n- **Runner architecture and instruction set**: ARM, x86. This is important when using emulators.\n- **Environment variables** : Some are set by the CI system (for example: `ANDROID_HOME`) and you can set your own to, for example, avoid hardcoding credentials in your workflow.\n\nThere are many other aspects you should consider, such as the number of cores\navailable, and whether virtualization is enabled to run emulators.\n\nLogs and reports\n----------------\n\nWhen a step fails, the CI system notifies you and usually doesn't let you merge\nthe change. To find out what has gone wrong, look for errors in the logs.\n\nAdditionally, building and testing generates reports that are usually stored as\nartifacts of that particular build. Depending on the CI system, you can use\nplugins to visualize the results of those reports.\n\nCache and CI run times\n----------------------\n\nCI systems use a build cache to speed up the process. In its simplest form, they\nsave all the Gradle cache files after a successful build and restore them before\na new one. This relies on [Gradle's build cache](https://docs.gradle.org/current/userguide/build_cache.html) feature and should be\nenabled in your project.\n| **Note:** take into account the time that it takes for the cache to download as, if the cache becomes too big and it contains more than is necessary, it could be detrimental to the overall build time.\n\nSome ways to improve run times and reliability include:\n\n- **Modules**: Detecting which modules are affected by a change and only building and testing those.\n- **Skip caches**: If the build includes scripts that a developer has modified, ignore the build caches. It's safer to build from scratch.\n- **Shard tests**: Especially instrumented tests, it can be helpful to shard tests across multiple devices. This is supported by the Android runner, Gradle Managed Devices and Firebase Test Lab.\n- **Shard builds**: You can shard the build across multiple server instances.\n- **Remote cache** : You can also use [Gradle's remote cache](https://docs.gradle.org/current/userguide/build_cache.html).\n\nRetry failed tests\n------------------\n\nFlakiness refers to tests or tools that fail intermittently. You should always\ntry to find and fix the problems that generate flaky builds and tests, but some\nof them are difficult to reproduce, especially when running instrumented tests.\nA common strategy is to retry test runs whenever they fail, up to a maximum\nnumber of retries.\n\nThere is no single way to configure retries, as they can occur at multiple\nlevels. The following table outlines the action you might take in response to a\nflaky test failure:\n\n| Failure | Action |\n|--------------------------------------------------------------|-----------------------|\n| Emulator was unresponsive for a second, triggering a timeout | Rerun the failed test |\n| Emulator failed to boot | Rerun the whole task |\n| There was a connection error during the code checkout phase | Restart the workflow |\n\nIt's important to log and keep track of which parts of the system are flaky and\ninvest in keeping CI reliable and fast, only relying on retries"]]
