How did you go from "manual upload to file server" to Docker+Gitlab?

We've been shipping MVPs long before those were a thing.

./deploy.sh runs the commands you used to run manually.

What problem are you solving now with containers?

Listen to what you are saying: "It will take little time" and "it will be worth it down the line". These are bets. People get this wrong all the time.

Don't take the bet. That's happy path thinking. Take the shell script and 0 dependencies on external services and complex software.

Dockerfiles are just a few lines of shell script and a single shell command away from a fully reproducible image that can be run anywhere. They are also reusable across projects. This is a point where you can easily carry over your productivity if you are constantly starting new projects. Your latest project will be much further ahead on day 1 than your first project. Compare that to manually typing in commands on a server to set your production environment up. You'll forget things (massive drop in productivity) or have to write them down (massive drop in productivity). You'll redo the same stuff over and over (massive drop in productivity). For what gain? Just to stay purist?

You are taking the advice way too far. The advice is do things that increase your productivity and many things that increase productivity are also easy to setup once you know them. I'm not saying that you should learn containers for the sake of your startup. I am saying that tools you already know well often require very little effort to setup and pay dividends immediately.

> How did you go from "manual upload to file server" to Docker+Gitlab?

When I learned what I said: it takes little time to set it up and you reap the benefits. If you don’t know how to use it then it’ll take some time to learn, in such case I see value going with whatever you know.

>We've been shipping MVPs long before those were a thing.

That reasoning can be used with almost any technology and doesn’t tell anything.

>./deploy.sh runs the commands you used to run manually.

You went from “manually copying” to having a script with reproducible steps. You’re closer to CD than what you were thinking.

I think the rest of the comment doesn't need to be addressed.

> But containerization and CI/CD? If you've some experience with it you know it's something that takes little time and money to set up (e.g. GitLab CI) and you get tons of benefits - you don't need to get super fancy either

This - CI/CD during development pays off so fast it's not worth skipping.

I don't regret setting up CI; it has saved us quite some time already with broken PRs (haven't tried CD, and I won't before we sell this thing :p).

Disclaimer: I am building a product to address the same need for getting started with SaaS products as a kit, including Docker, Kubernetes, CI/CD and more: https://saasstarterkit.app/

I strongly agree with this. Investing into a quick setup for CI/CD in the beginning of a project pays of really quickly. Every time someone comes up with a "simpler" suggestion to deploy things, I find it always tricky and not-so-simple because of the following questions: - which machine do I deploy my code to? should I use an existing VM or should I get a new one? - what dependencies do I need to have on the machine? do I install them manually for each project? - how do I deploy multiple projects on this machine? what if the dependencies conflict? - how do I get the code to the instance? Should I use SCP, or Git, or some other method? - once the code is in the machine, how do I start it? how do I ensure it is running? - how do I securely expose it to the internet? - how do I serve multiple projects from the same instance?

Obviously, each of these questions have answers and they can be solved, potentially "simply" for some; but for myself, I found these to be way harder to deal with then a few lines of Kubernetes configuration. I use Docker for packaging the application, I build everything on GitLab CI, and just deploy to the same Kubernetes cluster for all of my projects. With this setup, I still use a single instance and have very low stable costs, and I can deploy 10+ projects on the same cluster since they have small load for now. Everything is standardized, and I can get to live in minutes even for a new project.

I believe the idea that these tools overcomplicate things need to ba taken on a case-by-case basis. For some, it works; for others, it won't, just like any other custom script or "simple" solution.

> But containerization and CI/CD?

It is. For a very small startup, with not outside funding, everything that is not DIRECTLY related with A) Getting a paying customer. B) Launching, is a complete waste of time.

Please note this is not the only game in town (if you are Boston Dynamics by all means take all the time in the world to make those robots awesome) but if you are Yet Another Small Saas company for the love of god, launch, launch, launch.This is the game you chose to play.I dont care if your control version system are different folders and your backup are floppy disks, just launch and see if you can get people giving money to you for your product.

I have a tiny application. Yet it involves 5 containers. Some of the applications are a pain to install unless you go with a specific linux distribution and use their existing package. I don't have the time to manage all that crap through a labor intensive method or manage 5 separate servers when I can do it on one with containers. When I have to do things quick and dirty I just use a shell script with docker run and that's fine for 90% of projects because they don't pan out anyway. I can trivially switch to docker compose and then if I need scaling go to Kubernetes. It's a 100% solution. For the smallest prototype to large scale solutions. If you manage your servers manually you will either have to learn ansible which is just plain awful and difficult to use or you spend a lot of time doing everything yourself. Both cost time at the start of a project and many people don't have that time to waste on useless purism.

No way, maybe if you're working alone, but if there's even just two of us 'collaborating' via 'different folders and floppy disks' is going to slow me down, not speed me up.

It was hyperbole ffs, today it is more difficult to use floppy disks than Github. The point is that you dont need all the fancy stuff that more established companies with 10X-1000x more employees than you use.

Appreciate that re floppy disks specifically, I believe I did take it as intended, I was reacting to just sharing dumb directories - however they're pushed about - more than anything. I use git for things I work on alone, I find the ability to branch and stash etc. a net productivity improvement, not something that hampers me; add in collaborating with even one other person and I wouldn't even consider not using it, I'd honestly decline a job offer (well, everything has its price I suppose..!) over it, there's no way that's not a nightmare.