То, что вы описываете, не является "инкрементной сборкой". Вы описываете гораздо более сложную ситуацию, чем инкрементная сборка.
То, что вы описываете, никогда не было готовым вариантом, и на самом деле это невероятно сложно сделать правильно, и в конечном итоге это вероятно, не так сильно повлияет на вещи, как вы надеетесь.
Прежде всего, на самом деле очень сложно определить подмножество файлов, которые изменились между развертываниями. А если вы правильно строите и разворачиваете, то вы делаете единственную сборку и разворачиваете ее по конвейеру сред. Это означает, что «что отличается» в любой момент времени потенциально различно для каждой среды в вашем конвейере. Пример: у DEV есть версия 5, у QA - версия 4, а у PROD - версия 3. Поэтому вы должны начать с предположения, что собираетесь использовать самую старую версию. Системы сборки не имеют врожденных знаний о «выпусках», поэтому вам нужно будет что-то встроить в свои конвейеры сборки и выпуска, чтобы отслеживать, какая исходная версия представляет собой последний код в производстве.
Допустим, вы решили проблема. Теперь у вас есть возможность получить только дельту между тем, что развернуто в рабочей среде, и созданным коммитом.
Если вы работаете со скомпилированным кодом, то вам все равно нужен весь исходный код, потому что вы придется восстановить все это. Каждая сборка будет восстановлена, и разные метаданные во время компиляции будут означать, что эти сборки различны, даже если код, который составляет эти сборки, одинаков. А поскольку сборки могут ссылаться на другие сборки, у вас нет простого способа определить во время сборки, какие сборки действительно изменились и должны быть развернуты. Таким образом, у вас практически нет другого выбора, кроме как каждый раз развертывать все скомпилированные ресурсы. Обратите внимание, что это все еще относится к TypeScript или ко всему, что проходит через процесс компилятора / транспилятора; вам нужен весь доступный код, и он должен go на протяжении всего процесса сборки.
Таким образом, на этом этапе вам все еще нужно собрать все приложение, чтобы получить развертываемый вывод. Время сборки вообще не уменьшилось. Тем не менее, вам удалось отключить только подмножество содержимого c (т. Е. HTML страниц, изображений и т. Д. c). Возможно, это немного ускорило ваши развертывания!
Однако, если процесс сборки и развертывания замедляется тем, что у вас есть тонна не связанных с кодом стати c контента, тогда вы ' Мы прошли очень долгий и запутанный процесс, чтобы найти гораздо более простое решение: Переместить контент stati c в CDN и вывести его из-под контроля исходного кода, или создать отдельный процесс, управляющий stati c содержимое, чтобы его можно было развернуть независимо от несвязанного кода приложения.
Вы на самом деле не предоставили никакой информации, которая может быть использована для предоставления рекомендации о том, как действовать, но, надеюсь, этот ответ поможет понять, почему то, что вы хотите сделать, не решит вашу проблему, если только вы не имеете дело со стати c контентом или сценариями, которые не требуют сборки.