시스템이 워크플로를 실행하는 하드웨어 및 소프트웨어 환경을 선택하고 이해하는 것이 중요합니다. Android 애플리케이션의 중요한 고려사항은 다음과 같습니다.
플랫폼: Linux, Mac, Windows 및 각각의 버전입니다.
사용 가능한 메모리: 앱을 빌드하고 에뮬레이터를 실행하면 많은 RAM이 사용될 수 있으며 메모리 부족 오류를 방지하기 위해 JVM의 힙 크기와 같은 매개변수를 조정해야 하는 경우가 많습니다.
사전 설치된 소프트웨어: CI 시스템은 일반적으로 자바 개발 키트 (JDK), Android 소프트웨어 개발 키트 (SDK), 빌드 도구, 플랫폼, 에뮬레이터와 같이 이미 사용 가능한 대규모 도구 모음이 포함된 이미지를 제공합니다.
실행기 아키텍처 및 명령 집합: ARM, x86. 이는 에뮬레이터를 사용할 때 중요합니다.
환경 변수: 일부는 CI 시스템에 의해 설정되며 (예: ANDROID_HOME) 사용자가 직접 설정할 수 있습니다. 예를 들어 워크플로에 사용자 인증 정보 하드코딩을 피하도록 설정할 수 있습니다.
사용 가능한 코어 수, 에뮬레이터 실행을 위해 가상화를 사용 설정했는지 여부 등 고려해야 할 다른 여러 가지 측면도 있습니다.
로그 및 보고서
단계가 실패하면 CI 시스템에서 이를 알리며 일반적으로 변경사항을 병합하도록 허용하지 않습니다. 어떤 문제가 발생했는지 알아보려면 로그에서 오류를 찾아보세요.
또한 빌드 및 테스트를 수행하면 일반적으로 특정 빌드의 아티팩트로 저장되는 보고서가 생성됩니다. CI 시스템에 따라 플러그인을 사용하여 해당 보고서의 결과를 시각화할 수 있습니다.
캐시 및 CI 실행 시간
CI 시스템은 빌드 캐시를 사용하여 프로세스 속도를 높입니다. 가장 간단한 형태의 경우, 빌드에 성공하면 모든 Gradle 캐시 파일을 저장하고 새 캐시 파일을 만들기 전에 복원합니다. 이 기능은 Gradle의 빌드 캐시 기능을 사용하며 프로젝트에서 사용 설정해야 합니다.
런타임과 안정성을 개선하는 방법은 다음과 같습니다.
모듈: 변경사항의 영향을 받는 모듈을 감지하고 이러한 모듈을 빌드하고 테스트합니다.
캐시 건너뛰기: 개발자가 수정한 스크립트가 빌드에 포함된 경우 빌드 캐시를 무시합니다. 처음부터 빌드하는 것이 더 안전합니다.
샤드 테스트: 특히 계측된 테스트에서 여러 기기에 테스트를 샤딩하는 것이 유용할 수 있습니다. 이 기능은 Android 실행기, Gradle 관리 기기 및 Firebase Test Lab에서 지원됩니다.
결함은 테스트나 도구가 간헐적으로 실패하는 것을 의미합니다. 불안정한 빌드와 테스트를 생성하는 문제를 항상 찾아서 수정해야 하지만 그중 일부는 특히 계측 테스트를 실행할 때 재현하기 어렵습니다.
일반적인 전략은 테스트가 실패할 때마다 최대 재시도 횟수까지 재시도하는 것입니다.
재시도는 여러 수준에서 발생할 수 있으므로 단일 방법으로 재시도를 구성할 수 있는 방법은 없습니다. 다음 표에는 불안정한 테스트 실패에 대응하여 취할 수 있는 작업이 요약되어 있습니다.
실패
작업
에뮬레이터가 1초 동안 응답하지 않아 시간 제한이 트리거됨
실패한 테스트 재실행
에뮬레이터를 부팅할 수 없음
전체 작업 재실행
코드 결제 단계에서 연결 오류가 발생했습니다.
워크플로 다시 시작
시스템의 어느 부분이 불안정한지 로깅하고 추적하고, 재시도에만 의존하여 CI를 안정적이고 빠르게 유지하는 데 투자하는 것이 중요합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[null,null,["최종 업데이트: 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"]]
