Welcome to devops.stackexchange.com.
What works best is dependent upon the team. Find a good tool for the team and perhaps change that when the circumstances change. Also you might do a little thinking ahead to work out what approach might be best fit for the near future (e.g., will my team expand? will my number of servers expand? will I have a security audit in the future?)
Another key question is what capacity or curiosity do you have to explore a few options. If someone is trying to learn devops thinking about getting work at a startup then learning the latest free SaaS tools is a good idea. If you want to work in a regulated industry then a different set of tools are more appropriate.
Always the first place to start is “what do developers using the same languages and frameworks do?” As another answer says you should look at npm plugins to see how they deploy. We can think of that npm as “an ecosystem” and it’s a good idea to follow the crowd for a while to understand what’s normal in terms of, say, managing configuration differences between test and live environments.
In the npm world (say, node.js or reactjs) one typical way to manage setting is a .env file. If it has passwords are you confident about putting that file into git? Consider using git-secret to encrypt the file into git. What happens if you have a settings for local laptop, another for a test server and a third for a live server? How to you manage which one is used when you deploy to which server? Well npm lets you add any number of “scripts” into your package.json and you can have it rename the .env.live or .env.test to be .env on the server when you run the script as an npm command to deploy to either live or test servers.
Many advanced readers will cringe at that simple suggestion. These is because as well as the developer ecosystem there is also the deployment ecosystem. If you deploy into Kubernetes then it has featured like configmaps and secrets that are designed to share config and passwords between many applications. If you deploy to VMs in a company that uses, say, Ansible then its worth while looking at how that ecosystem managed configuration.
Pushing out code directly from your laptop to a couple of servers using an npm command isn’t acceptable at most companies. Did the developer remember to commit the code to source control? It would be a nightmare to have a bug in live but not know exactly what code is running there. For a hello world app that’s not a problem. For a massive reactjs app and a real business application it is a very real problem. The standard solution to this problem is to use a build server or more exactly a “CI/CD pipeline”. That stands for continuous integration / continuous delivery. It will check out your code from git, then build and deploy automaticafrom to the correct servers.
If you are a startup using a SaaS build service is probably the way to go. Take a look at circleci, travis, bitbucket or any number of free for small teams build pipeline services. If your code is in git they can be setup to build and deploy your code “in the cloud” every time you push code to git. They can be configured to deploy successful builds to your servers.
Regulated industries typically don’t build in the cloud (so far, that’s changing fast). They tend to pick a CI/CD build pipeline product to setup and manage themselves. Which ones they tend to use is “an ecosystem choice”. The C# world will use Microsoft products. The Java world often Jenkins is a default answer. So if you are learning with the intention of working at big companies it’s worth investing time in getting to know such products. They will be confusing at first as they solve problems that aren’t problems for solo developers who can use simpler approaches as described above.
Devops is a journey of continuous improvement not a destination. Start small and get something working. Then consider how it might be improved and upgrade the approach as needed to work more efficiently with less risks of errors through better automation.
