Migracja z TeamCity + Octopus do GitHub Actions

Cześć,
mam dylemat architektoniczny i liczę na doświadczenia osób, które przerabiały podobny temat.

Pracuję w międzynarodowym korpo, gdzie przez lata IT w poszczególnych krajach działało dość niezależnie. W polskim oddziale mieliśmy klasyczne on-premise setup:

• serwery Windows z IIS hostujące aplikacje
• repozytoria na GitHub (commercial)
• TeamCity z agentami na serwerach on-prem
• osobny serwer z Octopus Deploy

Flow wyglądał tak:

• TeamCity budował aplikacje, wrzucał artefakty na serwer z Octopusem,
• Octopus wykonywał deploymenty na kolejne środowiska (DEV / UAT / PROD).

Ruch sieciowy był odpowiednio skonfigurowany – Octopus łączył się z targetami po porcie 10933 (Tentacle).

Niestety zapadła centralna decyzja, że:
nie dostaniemy już licencji na TeamCity ani Octopusa
jedynym dopuszczalnym rozwiązaniem CI/CD są GitHub Actions (pipelines)

I tu zaczynają się schody
Ruch sieciowy do serwerów aplikacyjnych jest mocno zablokowany. De facto jedyny dozwolony wcześniej scenariusz deployu to był Octopus → target servers (10933).
Nie chcemy instalować GitHub Runnerów na każdym serwerze ani odblokowywać ruchu z GitHuba do całej infrastruktury on-prem

Rozważałem kilka opcji:
Web Deploy (msdeploy)

• testowałem, ale rozwiązanie jest dość toporne
• problemy z pełnym zarządzaniem IIS (np. pule aplikacji, uprawnienia itd.)

Własne „mini-Octopus”

• GitHub Actions buduje aplikację
  paczka trafia na jeden serwer on-prem (ten, na którym wcześniej był Octopus)
• z GitHuba wysyłany jest request HTTP do naszej aplikacji odpowiedzialnej za deploy, która pobiera paczkę i wykonuje deploy lokalnie na danym serwerze (IIS, konfiguracja, restart itp.)

To rozwiązanie technicznie wydaje się wykonalne, ale mam spore wątpliwości, wygląda to jak wymyślanie koła na nowo. mam poczucie, że ten problem był już rozwiązywany setki razy i mam obawy, że skończymy z customowym potworkiem do utrzymania przez lata

Pytanie do Was, jakie sensowne, sprawdzone podejście polecilibyście w takiej sytuacji?
Czy istnieje jakiś „standardowy” sposób na deploy z GitHub Actions do on-prem przy bardzo ograniczonym ruchu sieciowym (pull zamiast push)?

Każda sugestia, przykład z życia albo nazwa narzędzia będzie bardzo pomocna.
Z góry dzięki

Ostatnio czytałem o analogicznym setupie jak masz tylko ścieżka: GitLab -> TeamCity -> Octopus Deploy na OnPrem. Zamiast GitHuba stwierdzono, że będzie Azure DevOps. Nagle właśnie zaczęły się problemy i pytania jak tu działać skoro część aplikacji jest mobile, ale bez sklepu Play / App Store tylko aplikacje na użytek wewnętrzny.

Z mojej perspektywy kwestia, bo Azure lepsze widzę tylko tyle, że trzeba stawiać wszystko od 0 i będzie drożej. Dodatkowo masa pracy z segmentacją sieci i wnioskami o uprawnienia.
Wyczytałem i jest kilka opcji, ale najbardziej sensowna to postawienie 1 lub kilku maszyn u Was w DMZ z GitHub Runnerami oraz model pull.

Runner ma wtedy dostęp:

• do GitHuba (outbound)
• do serwerów IIS (lokalnie lub po LAN)
• żadnego inbound z Internetu

Runner:

• wykonuje deployment
• zarządza IIS (WebAdministration / PowerShell)
• kopiuje pliki / rozpakowuje paczki
• restartuje pule aplikacji

Na moje ktoś kto podjął taką decyzje architektoniczną teraz powinien wziąć za to odpowiedzialność, bo i tak niezbędne będą do zakupu kolejne maszyny OnPrem na Runnery, bo nie mogą to być aktualnie używane (kwestie bezpieczeństwa i zachowanie ciągłości aktualnych deploymentów). Niektórzy robią jakieś własne customy, ale po paru latach i tak się zrobi spaghetti, a finalnie będzie to robiło i rozwiązywało dokładnie takie same problemy jak aktualny setup. Biznes pewnie myśli liczbami, krótkoterminowo, ale w dłuższej perspektywie na moje to się nie opłaci i skończycie z 2 równoległymi środowiskami przez wiele lat, aż przyjdzie ktoś nowy i powie, że teraz fancy jest coś zamiast GitHuba. Ktoś musi generować niepotrzebną robotę zamiast myśleć jak zwiększyć zyski w innych obszarach lub ograniczyć koszty.