I-dockerize ko ang iyong Node.js, Next.js o Rust app at i-set up ang CI/CD gamit ang GitHub Actions o GitLab CI

Kung ang iyong pag-deploy ay isang listahan ng mga command na kailangang tandaan ng isang tao, pinapalitan ito ng serbisyong ito. Ginagawa ko munang reproducible ang app, pagkatapos ay awtomatiko: ang parehong imahe ay tumatakbo sa isang laptop, sa CI at sa server, at ang isang push sa pangunahing sangay ay ang lahat ng kailangan para sa isang release.

Ang Starter ay ang container: isang production Dockerfile, isang compose file na nagpapatakbo ng app at database nito nang lokal, at isang README na nagpapatakbo ng isang bagong developer sa isang command. Ang Standard ay nagdaragdag ng pipeline na nag-i-install, nagli-lint, nagpapatakbo ng iyong mga pagsubok at nagtatayo ng imahe sa bawat push at bawat pull o merge request. Tumatakbo ito sa GitHub Actions o GitLab CI, depende kung saan nakatira ang iyong code. Ang Advanced ay nagdaragdag ng deploy: sa pagsasama sa main, ipinapadala ng pipeline ang app sa iyong Linux server sa pamamagitan ng SSH o sa Railway o Fly.io, na nagpapatakbo ng parehong imahe, o nagbibigay ng Next.js app sa Vercel, na nagtatayo nito sa sarili nitong paraan. Ang mga deploy key at token ay pinananatili sa mga naka-encrypt na lihim ng GitHub o mga protektadong CI/CD variable ng GitLab, hindi sa code, at makakakuha ka ng nakasulat na paraan upang mag-roll back.

Ang mga imahe ay nananatiling maliit sa mga multi-stage build, ang app ay tumatakbo bilang isang non-root user, at ang configuration ay nagmumula sa mga environment variable, kaya ang parehong imahe ay nagsisilbi sa staging at production. Ang parehong diskarte ay sumasaklaw sa mga Node.js at Next.js app, mga serbisyo ng Rust at mga static na site.

Ang aking dalawang pampublikong web project, isang Next.js storefront at ang aking personal na site, ay nagpapakita ng pipeline side nito: Ang GitHub Actions ay nagtatayo at nagde-deploy ng pareho sa bawat push sa main branch, at nagpapatakbo ng unit at browser tests ng storefront bago ito i-deploy. Ang mga ito ay mga static na site, kaya ipinapadala ang mga ito nang walang container. Sa panig ng Rust, ang aking open-source crate ay may GitHub Actions pipeline na tumatakbo sa bawat push sa main at bawat pull request: formatting, lints, tests, ang minimum na sinusuportahang bersyon ng Rust at mga dependency check. Kung nagpapatakbo ka rin ng Kubernetes, ang mga manifest o isang Helm chart ay available bilang isang add-on.

Walang tawag. Ang lahat ay nakatira sa iyong repositoryo at nakasulat, kaya ang pipeline ay hindi nakasalalay sa akin. Para sa 14 araw pagkatapos ng paghahatid, inaayos ko ang anumang hindi gumagana ayon sa aming napagkasunduan, nang walang bayad.

Mga Hakbang para sa pagkumpleto ng iyong proyekto
1. Basahin ang proyekto - Pinapatakbo ko ang app sa paraang ginagawa mo ngayon at isinusulat ang mga dependency nito, environment variable, database at mga hakbang sa pagbuo.
2. Container - Isang production Dockerfile at isang compose file para sa mga lokal na pagpapatakbo, na sinuri sa pamamagitan ng pagbuo at pagsisimula ng app sa isang malinis na makina.
3. Pipeline - I-install, lint, mga pagsubok at ang pagbuo ng imahe sa iyong CI, sa mga push at sa pull o merge request, na may caching upang manatili itong mabilis.
4. I-deploy - Sa Advanced, isang trabaho na nagpapadala ng app sa pagsasama sa main, na may mga key at token na pinananatili sa mga lihim ng CI platform at isang rollback step na nakasulat.
5. Paglilipat - Isang seksyon ng README kung paano patakbuhin, subukan at ilabas, at kung ano ang babaguhin kapag nagdagdag ng bagong environment variable o serbisyo.