| These solutions do not need to look for a problem. They solve very real pain points. I am old enough that I remember doing the things “ssh to server and rsync” way. Heck I do it sometimes still for my personal projects. Here are the examples of the problems that CI/CD tools solve. 1. You rsync your working directory to a server, ssh to it and restart the server. That’s your only server. While you server restarts, your customers experience downtime. If you used modern tools, your tooling would automatically do rolling deployment or blue green of multiple load balanced instances. 2. Your service does not come up because in your local development environment you used the constructs from Python 3.11 that are not understood by Python 3.8 that is pre-installed on the server. What do you do? Upgrade Python of course. This breaks something else running on the same server. Would not be a problem if you deployed a dockerized app. 3. You figured out the Python version problem (all the while your customers could not access your service). Service starts up and crashes after a couple of minutes. Analyzing the stack trace you realized that this is a bug that would be caught by your unit tests - have you not forgot to run them before the deployment. Would not be a problem if running tests was a pre requisite for deployment. 4. At this point you give up and decide to roll back to the previous version. You go through the manual steps of extracting old version, rsync-ing or ftp-inc it again, restarting the servers (good thing you have only one server, right?). All the while service is still down for your customers. Whereas with modern tooling that would be a push of a button. 5. Your boss calls. They are rightfully angry that customers cannot access the service and asks why you did not ask for permission or a sign off for a prod deployment. You said you confirmed with Sue, verbally, but Sue has left the company and any audit trail of that is lost. Modern tools would give you an audit trail of an approval. 6. Jarred by this experience you decide to deploy to at least two servers. Congratulations - now you have to do twice as much ssh-ing and rsync-ing in a carefully orchestrated manner. Let alone that now you have to deploy some sort of a load balancer too. Modern tools do it for you behind the scenes. 7. Suddenly your product is very successful and you get much more of traffic. Your two servers are barely handling the load. And now you cannot do deployments at all because if you stop one of the servers the other will crash under load immediately. You need more servers. Of course you still use physical machines and you need more of them. You call your procurement. They give you two months of the lead time. On the cloud you would just move a slider in some interface and off you go. I could continue but hopefully you get the idea. |