Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Измерьте, где уходит время
Конвейер frontend-приложения выполняется пятнадцать минут, и команда хочет включить кеш для всего рабочего каталога. Сначала разделите длительность на получение исходников, установку зависимостей, тесты и сборку. Оптимизировать нужно реальный узкий этап. Сохранение всего каталога может ускорить один запуск, но скрыть отсутствие нужного шага или подмешать старый результат. В пилоте выберите один менеджер зависимостей и одну ветку. Зафиксируйте время чистого и повторного запуска. Цель — воспроизводимое ускорение без изменения результата, а не красивое единичное число после удачного попадания в кеш.
Разведите назначения файлов
Кеш используется для повторного применения зависимостей и каталогов между запусками. Артефакты передают нужные результаты шагов дальше по конвейеру. Например, кеш менеджера пакетов уменьшает повторное скачивание, а каталог сборки становится результатом, который проверяется или публикуется следующим шагом. Не используйте кеш как единственное хранилище релизного артефакта. Его отсутствие не должно ломать корректную сборку. Также не складывайте в него секреты, временные конфигурации production и полные дампы окружения. Перед настройкой перечислите файлы каждого назначения, владельца и ожидаемую продолжительность жизни. Это предотвращает случайное смешение зависимостей, результатов и чувствительных данных.
Настройте ограниченный кеш
Bitbucket Pipelines поддерживает предопределённые и пользовательские кеши; для пользовательской настройки доступны параметры пути и ключа. Выберите каталог, соответствующий используемому инструменту, и проверьте актуальную документацию его поведения. Если ключ связан с файлами зависимостей, изменение lock-файла должно приводить к ожидаемому обновлению. Не называйте переменную PATH произвольным каталогом кеша: системные имена могут менять выполнение команд. Установка зависимостей остаётся явным шагом. Для приложения используйте режим, который следует зафиксированному lock-файлу, если он поддерживается менеджером пакетов. Кеш должен помогать этому шагу, а не заменять проверку согласованности зависимостей.
Передавайте только необходимые артефакты
После сборки объявите минимальный набор выходных файлов, который нужен следующему шагу. Пути артефактов в Bitbucket задаются относительно каталога клонирования; проверьте точный шаблон и фактическое содержимое. Добавьте файл с commit и контрольной суммой результата без секретных значений. На шаге публикации убедитесь, что получен ожидаемый результат, а не создан новый из другого набора зависимостей. Не включайте весь рабочий каталог ради удобства. В него могут попасть журналы, временные токены или данные тестов. Просмотрите состав архива вручную на пилотном запуске и ограничьте доступ к результатам по вашему процессу.
Проверьте четыре сценария
Выполните сборку без кеша, повторную сборку, сборку после изменения lock-файла и запуск после ручной очистки кеша. Во всех случаях итог должен проходить одинаковые проверки. Отдельно убедитесь, что следующий шаг получает именно артефакт текущего запуска. Сравнивайте не только время, но и состав выходных файлов, результаты тестов и идентификатор версии. Если после очистки возникает ошибка, кеш скрывал зависимость, которую нужно сделать явной. Не восстанавливайте старый кеш как постоянное исправление. Найдите отсутствующий пакет, неверный путь или пропущенный этап и повторите чистый запуск после устранения причины.
Откатите оптимизацию при нестабильности
Храните изменение кеширования отдельным понятным diff, чтобы его можно было быстро отключить. Если появляются плавающие ошибки, сначала вернитесь к чистой установке и проверьте воспроизводимость. Удаление кеша не отменяет опубликованный релиз и не меняет Git-историю. Для проблемного артефакта нужен отдельный процесс остановки публикации или отката приложения. После стабилизации вводите оптимизацию снова по одному каталогу. В документации репозитория укажите назначение каждого кеша и способ диагностики. Периодически сравнивайте чистый и повторный запуск: ускорение полезно только тогда, когда команда уверена, что правильность сборки от него не зависит.
Диагностика скрытого файла
Смоделируйте ошибку, при которой локальная сборка использует файл конфигурации, случайно оставшийся от предыдущего запуска. На чистом конвейере файл отсутствует, а при широком кешировании ошибка маскируется. Попросите инженера определить, откуда берётся зависимость, и выбрать правильный способ её формирования. Несекретный шаблон может храниться в репозитории, чувствительные значения должны поступать через согласованный механизм, а выходной файл должен создаваться явным шагом. После исправления очистите кеш и повторите сборку несколько раз с разными разрешёнными параметрами. Проверьте, что артефакты одного запуска не попадают в другой. Запишите минимальный набор входных данных, достаточный для получения результата. Это упражнение показывает, почему ускорение нельзя оценивать отдельно от воспроизводимости. Удобная сборка должна работать после полного удаления временных файлов, иначе следующая смена окружения снова вернёт скрытую проблему.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу