What is your website deployment process like?
For me, I initialized an upstream git repository on my remote server with a git hook that runs a script on post-receive that kills/stops all running docker containers and starts a new one, booting up the newly pulled code.
Please no static site faggots in this thread
Static site on S3.
Problem, dynamicfags?
For my personal projects I push to the master branch of PROJECT's repo.
I have a Common Lisp service that is hit by Git's webhook. Builds the new Docker image, distributes it to my RPI Docker Swarm, updates the Docker Swarm service.
That's it. All load balanced, Let's Encrypt niceness. So easy.
I'm a semi-static site faggot.
All my html pages get rsync'd to the server, and any webapps get their new binaries pushed automatically and restarted.
>Please no static site faggots in this thread
This is the only proper type of website faggot.
A bunch of PHP files on my Debian / Apache server. I edit the scripts online.
I'm working on new deployment/hosting infrastructure for my work.
It goes something like:
Git push
Jenkins
- Build (Docker)
- Deploy
Helm
- Deploy to kubernetes (Docker image)
Kubernetes
- Load balance
- Services
Etc....
There's more to it obviously but cbf typing it out.
You can't serve proper 404s or redirects with a purely static site. Hell, you can't handle most of the HTTP protocol with a purely static site.
gcloud app deploy
management jumped in to cloud meme and dotnet core
>git repo
>a cloud build agent triggers in every commit
>build agent in the cloud pulls repo
>restores all dependecies and builds solution
>build agent publishes to testing and staging server
>tester approves the shit and switches staging to deployment