How do you deploy stuff? And what is the tool you use for?

#discuss #devops #deploy

Hello! I would like to open a discussion about how to deploy and the tools use for that.

As context, I have worked at a company which use a "artefact" repo to store artefacts generated by the CI. Then, deployement servers were informed that there was a new artefact and they get them. Personnally, I use gitlab runner to deploy my blog with a rsync command (but honestly it feels dirty, but it work). I know also about the "git push as deploy", but I am not convinced either since you don't want the full repo but only a package solution.

So how do you deploy stuff?

Oldest comments (6)

Alan Barr • May 31 '18

At work tfs also known as visual studio team services vsts. In other lives has been bamboo or jenkins. So far all are capable of doing the jobs. For my personal stuff I like to write F# scripts or use FAKE.

Ben Halpern • Jun 1 '18

We deploy to Heroku via Codeship for CI and a Github workflow

Shayne Boyer • Jun 1 '18

I am a huge proponent of - "Just Check in my code".

git push ftw

Now to say that there is a lot behind enabling me or the developer to have that luxury. Some CI/CD system is there to do the heavy lifting. Could be Travis, Codeship or VSTS that

gets a webhook
pulls the code
builds the docker container
builds the code, runs the test
tags the container and pushes it the to registry
sends the webhook to deploy to production / staging or whichever environment

But in the end...just checking in the code should do what we need as developers.

Erik Nelson • Jun 1 '18

We use Travis CI to package our apps into Docker containers, which are published to a private repo on Docker Hub. From there we have some custom rolled deploy scripts that publish to Elastic Beanstalk on AWS.

This is all probably way overdone for your case.

John Munsch • Jun 1 '18 • Edited

I use Ansible for my deployments and I really love that I don't have to specially prep the servers I'm manipulating, nor do I have to have some server stood up to work with. It's a handful of scripts and a tool installed locally.

But, I really want to call out how important I think it is to have tooling not just for the deployment of your apps but also for provisioning servers. In my experience, being able to stand up a server and just point a script at it to have it fully configured for your deployments should not be dismissed. Trash even one server by accident and you will be so happy you have that functionality. It's also wonderful how well it pairs with a tool like Vagrant because you can "vagrant up" a server locally and have it provisioned exactly like a remote server in just a few minutes. It makes it trivial to test out ideas locally before you do anything to a server you have to pay for.

If your curious, here are my devops scripts in this repo here: gitlab.com/JohnMunsch/devops
The package.json file has all of the commands I run with "npm start [name of thing to do]" in it.

However, the one part of Ansible I'm not super fond of is how inscrutable some errors can be and how inconsistent the various modules you interact with can be. Also, sometimes you want the real language structures and power of a programming language like JavaScript (or whatever) and all you have is YAML files. Bleh.