How does deployment on remote servers work?

Question

I'm a bit new to version control and deployment environments and I've come to a halt in my learning about the matter: how do deployment environments work if developers can't work on the same local machine and are forced to always work on a remote server?

How should the flow of the deployment environments be set up according to best practices?

For this example I considered three deployment environments: development, staging and production; and three storage environments: local, repository server and final server.

This is the flow chart I came up with but I have no idea if it's right or how to properly implement it:

PS. I was thinking the staging tests on the server could have restricted access through login or ip checks, in case you were wondering.

Answer 1

I can give you (according to my experience) a good and straightforwarfd practice, this is not the only approach as there is not a unique standard on how to work on all projects:

• Use a distributed version control system (like git/github):

  • Make a private/public repository to handle your project

• local Development:

  • Developers will clone the project from your repo and contribute to it, it is recommended that each one work on a branch, and create a new branch for each new feature
  • Within your team, there is one responsible for merging the branches that are ready with the master branch
  • I Strongly suggest working on a Virtual Machine during Development:
    • To isolate the dev environment from the host machine and deal with dependencies
    • To have a Virtual Machine identic to the remote production server
    • Easy to reset, remove, reproduce
    • ...
    • I suggest using VirtualBox for VM provider and Vagrant for provisioning
    • I suggest that your project folder be a shared folder between your host machine and your VM, so, you will write your source codes on your host OS using the editor you love, and at the same time this code exists and runs inside your VM, is in't that amazingly awesome ?!
  • If you are working with python I also strongly recommend using virtual environments (like virtualenv or anaconda) to isolate and manage inner dependencies
  • Then each developer after writing some source code, he can commit and push his changes to the repository
  • I suggest using project automation setup tools like (fabric/fabtools for python):
    • Making a script or something that with one click or some commands, reproduces all the environment and all the dependencies and everything needed by the project to be up and running, so all developers backend, frontend, designers... no matter their knowlege nor their host machine types can get the project running very merely. I also suggest doing the same thing to the remote servers whether manually or with tools like (fabric/fabtools) The script will mainly install os dependencies, then project dependencies, then cloning the project repo from your Version Control, and to do so, you need to Give the remote servers (testing, staging, and production) access to the Repository: add ssh public keys of each server to the keys in your Version Control system (or use agent forwarding with fabric)

• Remote servers:

  • You will need at least a production server which makes your project accessible to the end-users
  • it is recommended that you also have a testing and staging servers (I suppose that you know the purpose of each one)

• Deployment flow: Local-Repo-Remote server, how it works ?:

  1. Give the remote servers (testing, staging, and production) access to the Repository: add ssh public keys of each server to the keys in your Version Control system (or user agent forwarding with fabric)
  2. The developer writes the code on his machine
  3. Eventually writes tests for his code and runs them locally (and on the testing server)
  4. The developer commits and pushes his code to the branch he is using to the remote Repository

  5. Deployment:

     5.1 If you would like to deploy a feature branch to testing or staging:

     • ssh access to the server and then cd to the project folder (cloned from repo manually or by automation script)
     • git checkout <the branch used>
     • git pull origin <the branch used>

     5.2 If you would like to deploy to production:

     • Make a pull request and after the pull request gets validated by the manager and merged with master branch
     • ssh access to the server and then cd to the project folder (cloned from repo manually or by automation script)
     • git checkout master # not needed coz it should always be on the master
     • git pull origin master
       • I suggest writing a script like with fabric/fabtools or use tools like Jenkins to automate the deployment task. Voilà! Deployment is done!

This is a bit simplified approach, there are still a bunch of other recommended and best practice tools and tasks.