I'm using Forge right now to deploy my app from my local machine to a server on DO and it set it to deploy automatically. If I wanted to introduce another server (so the current site on DO would become a staging site), what's the best way to manage it? Would I setup another site on forge and turn off automatic deployment? Once I'm satisfied with the staging site (make sure nothing is broken, everything works the way it should), deploy to production manually?
I wanted to hear what everyone else does or what the best practice is.
@clin407 I am thinking of doing exactly this myself. Your outline is pretty much what I was thinking. No thoughts from anyone else? In addition, I was thinking of adding the sub domain staging to the existing site so I could run both staging and production off the same DO droplet. Something like this;
DEV - local (push to Git Hub)
STAGING - staging.mysite.com (pull from Git Hub on auto deployment) - db1
PRODUCTION - www.mysite.com (pull from Git Hub manually only) - db2
Few places I have worked we have one repo on github usually called master the two main branches. Dev, and working. We as a team branch off working. When we are done merge back. When we hit a test state the working gets merged into dev. Dev gets pushed to a test server where it is tested. When it's good it merges to master which is deployed to a live server.
So I am starting to do just as outlined above and have a question. I created a new site in Forge called staging.mysite.com and then used the same repository on Git as my Production site. Now when I edit the environment for staging, how do I create a different db and user so I can test in staging without impacting production data? This was done when I spun up the server in Forge but there are no UI options when you generate a new site. Does this need to be done through the terminal?
