Dev site vs. production site
These are some very, "You are clearly new at this," kinds of questions, but I have never had the opportunity to get hands-on experience in a proper dev/production environment. I've only had experience with my own projects, so I've just been doing things my own way.
At the moment, when I want to make a change to my website, I do what I need to locally, and then to "push to production" I just drag and drop the relevant folders onto the server and carefully avoid adding anything to the production site that's specific to my local dev version of it.
This is obviously not how you do that, but I don't know what the alternative is or how to set it up.
So how does having a dev site vs a production site actually work?
How do you sync changes made to the dev site to the production site? Are these two websites separate branches that you maintain with git? How do I use git with a shared hosting Apache server (or anything, really, but this is what I have for hosting) that I have zero physical access to? The option for git is there, but when I use it, it just makes a new directory for me with no (easily understood) explanation on what I'm meant to do with it, likely because I'm expected to already know (which I don't). How would I link that to my local dev environment? I have repos on github--is it possible to link all of these things together somehow...? Would I even want to do that? My gut says no, but I don't know.
This is probably my biggest knowledge gap when it comes to this stuff, and I would really like to start filling it in if anyone has time to break it down for me, or tell me where I can start learning.
Thank you.
8 Replies
I'm not good at devops but how I've seen it done at the couple of companies I've worked at is that we'll have:
1) A staging site (for testing local development changes off of a production-like environment)
2) A QA site (optional)
2) A production site
Sometimes there can be a staging site -> qa site -> production site. But essentially the staging site is where you push your local changes, and then there's some pipeline to bring it to production. The staging site will typically have a copy of the production database
Let's say you're using Git. If you're using something like GitHub, there are ways you can use GitHub actions to push a branch to the server / site automatically. E.g if you have local changes, you'll make a feature branch. You'll then make a pull request to merge the feature branch into your
staging branch. After review, a senior will merge the changes from the feature branch to staging.
After a new commit is merged into staging, GitHub actions will run and automatically push that commit to your staging site. Same thing with QA and Prod versions. But that's just one way I've seen it done; I'm sure there's many other waysFrom what I've learned via various non-work-experience-things (blog posts, YT, discussions, podcasts, etc) is this:
Local dev work in a non-prod git branch. If it works, merge to prod and push to GH. Then once on GH there's [magic] that deploys to prod. This could be GH Actions, you pulling from GH to your server, or some auto-deploy script.
The important thing is to keep your
.gitignore file up to date so you don't push dev files to prod.
Many people are proponents of named-test branches. For example, if you're updating the log-in system you'll make a login-test branch or something like that. The branch name tells you what code it's working on. That way on bigger teams you could have three different dev branches, with three different people working on them (one per branch) at the same time. Just be sure to git pull frequently to get the latest prod branch so your code doesn't fall too far behindThere are different levels of complexity and many ways it can be done. If you have a static website or one that may need some SSR, there are plenty of server-less hosting services that handle all to of what you are talking about. They are actually pretty easy. I use Cloudflare Pages/Workers. But there is also have Netlify, Vercel, AWS, they are a dime a dozen and do similar stuff.
With these server-less hosting site usually it is as easy as merging a dev branch into main/master/prod, or creating and closing a Pull Request. These service providers will automatically build the site and deploy if it is successful. Some have a staging preview version you can check as well. You may be able designate the staging site to a specific branch. This essentially checks out and builds the site as the code exists on that branch.
Where I work we have many applications and they all deploy a little bit different. One app I was on had a Java backend and a dedicated staging server. Not sure how the server was setup. We have our own rack in a data center. But to test features I would use a CLI to access that server and checkout a branch. There some commands to kill processes and build/compile the backend code. This also ran our unit tests, then built the front end. If everything worked it would start the server and application.
We also do the same thing for publishing in GitHub with Github actions. So all of that stuff runs when we merge to master. If it fails it won't deploy the new code.
v1mind is on the money about having different branches. Typically we would have a hot fix branch which was a separate copy of master in case of fire that way we would not deploy code meant for our regular release. Also when working with teammates we would have integrations branches that the devs working on would branch off of for their portions. Always keep your branches up to date to limit merge conflicts.
How servers run and the code gets placed onto the server is outside of my wheel house. That is more DevOps and IT. I am learning a bit about it but not something I want to be an expert in.
The topic is called CI/CD pipeline. Continues Integration and Continuous Delivery/Deployment
fwiw, the way we used to do it at work is that we had release tags in our git repo, and would check out that tag on the production server. We'd also have a prepared set of SQL statements to do any database updates, and potentially an upgrade script for any filesystem changes. Upgrading prod, you just logged into the server, dit a
git pull followed by a git checkout release-6.5.1 or whatever the exact command was, and then did any of the other things that needed doing
CI/CD automation is fine, and pretty popular. More popular the bigger you are. But simpler processes exist, and smaller shops typically use them
(this is at a tiny SAAS provider btw, with a couple dozen clients(businesses) and a couple thousand end users)I learned in large enterprises how to set things up, but this is how I've done it in the past and even use to a certain extent for my own personal projects.
In git, you have the master/main branch. This is your source of truth. This is identical to what is on your production site.
Then there is the develop branch. That's the last step before it gets merged into master/main. This is what's used for testing/QA
Finally, you have feature/bugfix/hotfix branches. This is the branch that you work in when you're working on something. In a perfect world, you should only have one issue per branch, but sometimes, we would group related small issues into a single branch.
Your feature branches are created from develop. The only exception was when doing a hotfix, because in theory, develop would have changes that have not been tested yet and are not ready to be deployed to production
You do your work on the feature branch you've created. Merge in develop frequently, so you don't drift so far from it that you have merge conflicts and a headache when it gets merged to master/main.
When your work is done, if you're using GitHub, GitLab, BitBucket or something similar, you would push the branch up to the central repository, and then open a pull/merge request to merge your feature branch into develop (or master/main if it's a hotfix). One or more people would review your changes, possibly make suggestions or request changes, etc. When enough reviewers have approved your request and there are no open change requests, the branch gets merged.
/more
I won't get into CI/CD pipelines, which is another subject. But eventually, when the sprint or other development cycle is completed, develop would be deployed to a dev server for the developer (remember, this is a large enterprise company) to test and verify before handing off to the QA team. Once they've completed their testing, it would then be deployed to QA for the QA team to do the formal testing. After the develop branch has passed formal testing, it's merged to master/main and deployed.
Now, this is overkill from what you described your setup is. The way I have things setup for my personal projects is a variation on this. Since I'm the only developer, I just work on the develop branch, but if I ever bring other developers onto the project, I will start using feature branches. I have a small CI/CD pipeline setup, and after every push to the develop branch, it updates the cloned repository for the staging server (which just another virtual on the same server). Once I'm happy with the changes, I'll merge it to master and manually updated the cloned repository in the production server directory. A similar setup (without the CI/CD setup) will probably work for you. I'm not sure how to deal with your hosting company, but that's the basics of how I've done it and do it.
Oh wow you guys gave me like. A ton of good information, like more than I was expecting lol
I'm not really expecting to be part of anything big any time soon, I'm just really tired of making changes to a tiny website that I am the only developer on, having it work in my local environment, and then uploading using cPanel's file manager only to realize I left things in that shouldn't be in the production site yet and/or oops I overwrote the file that has the database credentials again. Like there's gotta be a better way, and I see now yeah, there definitely is lol.
I did recently figure out how to start using github and how to use branches, and that's already been world altering, but this stuff is going to help me so much more
Thank you all so much for giving me such a good baseline to jump off from; most of this stuff I've never heard of and I'm looking forward to digging up more about how these things work and how to set them up later
Yeah git is not as scary as it may seem at first. It takes time to learn git operations and really understand them. It is important to learn how to keep credentials secure early.
@Ray If you develop good habits now, even if it's just using git/github and branches, you won't have any trouble when you need something more complex