Gdy publikacje stają się rutyną,
zapisz je w komendzie
Przeciągnij pliki w przeglądarce dla pierwszego dowodu. Gdy ten sam statyczny build wychodzi regularnie, przenieś krok publikacji do terminala, CI albo playbooka, żeby start nie zależał od pamiętania o ręcznym przesłaniu.
Dla wydań, które robisz więcej niż raz
Nie opieraj procesu na pamięci
Komenda publikacji zamienia powtarzane przesyłanie plików w krok wydania, który zespół może udokumentować, przejrzeć i uruchamiać tak samo.
Pozwól CI dokończyć pracę
Jeśli GitHub Actions albo inny system CI już zbudował folder wynikowy, krok publikacji powinien wysłać ten folder bez ponownego ręcznego przesyłania.
Zachowaj ten sam model projektu
Zacznij od przesłania plików w przeglądarce, a potem przenieś ten sam projekt do automatyzacji, gdy stanie się realną ścieżką wydań.
Ręcznie na start, automatyzacja gdy zasłuży
Jednorazowe podglądy powinny zostać proste. CLI ma sens wtedy, gdy strona jest publikowana regularnie, sprawdzana przez zespół albo uruchamiana przez proces CI.
steps:
- uses: actions/checkout@v2
- run: npm install && npm run build
- run: npx @deploypages/cli deploy ./dist --token ${{ secrets.DEPLOY_TOKEN }}Częste pytania
Q: Czy to działa na Windows, macOS i Linux?
Tak. Użyteczna ścieżka CLI musi pasować do systemów, których zespoły używają przy lokalnych buildach i runnerach CI.
Q: Czy mogę kierować automatyzację do konkretnego projektu?
Tak. Publikacja skryptowana działa dobrze tylko wtedy, gdy zespół może jednoznacznie powiązać proces wydania z właściwym kontekstem projektu.
Q: Czy to pasuje do monorepo?
Tak. Zespoły z monorepo potrzebują ścieżki publikacji, która potrafi celować w konkretne katalogi robocze i foldery wynikowe.
Zacznij od części, którą ma każda strona statyczna
Prześlij zbudowane pliki, otrzymaj działający link HTTPS, a potem dodaj domeny, przywracanie wersji, statystyki, automatyzację i kontrolę zespołu, gdy projekt ich potrzebuje.