I am assuming you already have a basic knowledge of Bash, Git, SSH, and Ubuntu but I will try to make things as clear as possible so that, even if you are a newbie, you should be able to understand and follow the tutorial.<\/p>\n\n\n\n
Also, you will need to have Git<\/a> and NodeJs<\/a> installed on your local machine. The first thing to do is to have a server machine that we will need to be configured to serve our website. My advice is to get a basic VPS on DigitalOcean<\/a> or Linode<\/a>. It will cost you very little money ($5-10\/month) and you can shut down the machine once you are done with the tutorial and save the money for when you need to serve your next real website.<\/p>\n\n\n\n As an alternative, you can also use a local virtual machine to simulate a remote server. In this case, my advice is to go with Vagrant<\/a>.<\/p>\n\n\n\n In case you chose the first option, here are some tutorials that will explain you how to run a new machine and how to establish a connection through SSH:<\/p>\n\n\n\n In case you want to go with the local virtual machine option here’s another guide for you to get started with Vagrant<\/a>.<\/p>\n\n\n\n Whatever path you choose I expect you have the following requirements before moving on to the rest of the tutorial:<\/p>\n\n\n\n So, just to make things clear, we will work on two different machines. The local<\/strong> machine (our computer) for development and the remote<\/strong> machine (our server) as production environment to serve our website to the World. All the next paragraphs will be labeled with “(local)” or “(remote)” to make clear where we will perform our actions.<\/p>\n\n\n\n I am assuming your server is running Ubuntu (at the time of writing the last LTS version is 14.04). The first thing we need to do is to login with SSH to our server and install Nginx. In case you never heard of it, Nginx is one of the most famous web servers. It is really easy to install and configure and it also offers very good performances. You can use Apache as an alternative but we will stick with Nginx in this tutorial. To install Nginx on Ubuntu you just need to be sure you are connected to your remote server and to run the following command in your bash prompt:<\/p>\n\n\n If everything went fine we now have Nginx installed. If you open your browser and visit http:\/\/yourserver\/ (where yourserver<\/em> is the real IP or the domain name of your server) you should be able to see the default Nginx welcome page. We will change that later with our real website.<\/p>\n\n\n\n We will also need to have git installed on our server, so let’s add it:<\/p>\n\n\n For now, our server is ok, we will see in a moment how to configure it for our needs, but let’s create a new website on our development machine first!<\/p>\n\n\n\n In this paragraph, we will create a very simple website and start to version it using git.<\/p>\n\n\n\n Let’s just create a new folder in our local machine, open a command line shell in that folder<\/strong> and run:<\/p>\n\n\n For the sake of simplicity, on our website, we are going to have two files and a HTML home page and a CSS file.<\/p>\n\n\n\n Our HTML file is called Pretty simple! Now let’s move to our As a starting point, our css file includes Normalize.css<\/a>, an open source stylesheet crafted to minimize the differences in the way different browsers handles some properties. It helps web designer to obtain the same graphic layout through all the major browser.<\/p>\n\n\n\n So if we want to see how our new amazing web site looks like we just need to open our <\/p>\n\n\n <\/p>\n\n\n\n Isn’t a beautiful piece of art? Ok, maybe it’s not, but it’s a decent starting point for you next great thing \ud83d\ude42<\/p>\n\n\n\n Now let’s add the new files to our local git repository. Go to the command line and launch the following command:<\/p>\n\n\n Then we can make our first commit:<\/p>\n\n\n At this stage our git repository lives only on our local machine, so nobody will be able to read it from the outside, neither our server will be able to download the files when we want to release a new version of the project.<\/p>\n\n\n\n The next thing to do is to add a remote repository. To understand what remote repositories are let’s quote the official git documentation<\/a>:<\/p>\n\n\n\n To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read\/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.<\/p>\n<\/blockquote>\n\n\n\n So now we have one problem: where do we have to put our remote repository? The easiest solution is to get an account on GitHub<\/a> and create a new public repository there. GitHub is free to use for public repositories, but you can purchase a paid account to have private repositories in case your repository contains sensible information that you don’t want to share.<\/p>\n\n\n\n Once you have your account on GitHub, you can create a new repository<\/a> using their web interface:<\/p>\n\n\n <\/p>\n\n\n\n Let’s add a name and a description, be sure to select public<\/strong> and click the “Create repository” button.<\/p>\n\n\n\n Once done you should be able to see something like this:<\/p>\n\n\n <\/p>\n\n\n\n As you can tell, our project file are not there yet, let’s push<\/em> them!<\/p>\n\n\n\n To push our files we need to associate our local repository to the new remote one, so copy your repository address in the right column (you can choose Be sure to replace with the URL you copied from your GitHub repository page.<\/p>\n\n\n\n Now we have associated our local repository with the new GitHub remote one. GitHub creates some files when you create a new repository, so it’s a great thing to download them into your local repository:<\/p>\n\n\n This will make you ready to push our file to the remote repository<\/p>\n\n\n If you refresh your GitHub project page, you will now see all our project files are there.<\/p>\n\n\n\n We now have our website and our server and at this stage we can move to the core of our article: how to organize a process to simplify the deployment of our website in the new server.<\/p>\n\n\n\n There are hundreds of tools and SaaS platforms to manage complex deployment processes on one or more servers, but one of my favourite is Flightplan<\/a>. Flightplan is a NodeJS library that can be easily installed and configured to create a sequence of shell commands in our local machine and in our remote server to deploy and update our website or app.<\/p>\n\n\n\n The first thing to do is to install Flightplan in your local machine:<\/p>\n\n\n The first command installs Flightplan as a global command (the Now we need to create a configuration file inside the main folder of our project called Before writing the code in our Flightplan configuration file let’s understand what exactly we want to achieve and how we want to structure our files and folders to do so.<\/p>\n\n\n\n As we said, our objective is to be able to deploy a new version of our website with a single command and to be able to rollback to the previous version just by launching another command. So we expect to have at least two different commands: To achieve this goal we can structure the folders in our remote server as follows:<\/p>\n\n\n\n The flow we want to create for every deploy is the following:<\/p>\n\n\n\n Furthermore we want to add a nice feature to save disk space: we want to have a fixed numbers of deployed versions on the server (e.g. no more than 10), so we might need to delete the older ones at the end of every deploy.<\/p>\n\n\n\n It’s a lot of code, let’s analyze it piece by piece.<\/p>\n\n\n\n The remote configuration defines our production environment on our server and tells Flightplan how to connect to it and what the specific options for the server are. In more advanced setups you can also specify an array of servers to which the deploy will be carried simultaneously.<\/p>\n\n\n\n As you can see there are some configurations that you will need to change, like: The setup command is a helper command that you can launch once to configure the remote machine folders.<\/p>\n\n\n\n The command In the next lines we first create our web root folder, then inside that folder we create the The deploy command is, of course, the most important one, let’s review its code:<\/p>\n\n\n\n The first thing we do is to update the Then we clean up the old deploys using a handy bash short-liner command. The command lists and removes all the folders in the The rollback command allows us to restore the previous version and to delete the newest one, it’s like a step back in time.<\/p>\n\n\n\n What we do here is to use another bash short-liner to get the last 2 deployed versions inside the Ok, now that we have all our Flightplan commands ready we can launch off the first deploy.<\/p>\n\n\n\n For the first time we need to run:<\/p>\n\n\n to set up all the folders on our server, then we can launch our first deploy with<\/p>\n\n\n If we have done everything correctly our deploy should be successful and show a green dot! But wait… why our server still shows the default nginx page? Oh well, we still need to configure nginx to use our Get back to you ssh console and run:<\/p>\n\n\n This will open the nginx configuration file with the nano editor. Move the cursor down until you see a The last step to do is to force nginx to reload the new configuration:<\/p>\n\n\n Now get back to our website and refresh! Tad\u00e1! Our web server is now serving our new website! Cheer up!<\/p>\n\n\n\n Ok now maybe it’s time to realize that our new website it’s not so amazing, maybe it would be nice to add an image and change the background color. You can grab a very nice image from here<\/a>. Let’s update our HTML file:<\/p>\n\n\n\n We basically just added the paragraph with the image, but notice we also moved our stylesheet into its own And here we have it!<\/p>\n\n\n <\/p>\n\n\n\n I know, I know… it looks like one of that websites from the early ’90s, but let’s pretend it’s wonderful and we want to deploy this new version for now.<\/p>\n\n\n\n So first of all we need to commit our modifications. It’s always a good idea to launch a <\/p>\n\n\n\n There are some things to review here. First of all we moved our css file to the folder But it’s a good idea to not add the If you run <\/p>\n\n\n\n The To add all these new files and folders to our repository we need to launch the following git command:<\/p>\n\n\n Let’s launch <\/p>\n\n\n\n Now everything is green and git also recognized that we moved the css file to the new And then we can send this new version to the remote repository with:<\/p>\n\n\n Now it’s time to run our deploy script to update our remote server:<\/p>\n\n\n We should see a bunch of lines of output and then a green dot that confirms that our deploy went fine! Great, let’s now refresh our website page in the browser and see that our new version is online!<\/p>\n\n\n\n We are just cheering up for the update but after a couple of minutes one of our friends call us to say:<\/p>\n\n\n\n “Man, what’s happened to your website? It looks uglier than ever, I really loved the previous version!”<\/p>\n<\/blockquote>\n\n\n\n So yes, maybe we realize as well that the previous version had that kind of fascinating minimalism and that it’s better to rollback. Our Flightplan configuration it’s here to support us and make things simple, just run:<\/p>\n\n\n Let’s refresh your browser and tell our friend he was right!<\/p>\n\n\n\n Maybe it’s time to work on a better new version, but now you know how to do it on your own \ud83d\ude09<\/p>\n\n\n\n <\/p>\n\n\n In this article we learned a lot of useful things about how to keep our website versioned and how to deploy it easily. We used a bunch of interesting tools like git and Flightplan.<\/p>\n\n\n\n The article was focused on explaining the basics of these tools. You might have a dynamic website written in Php or NodeJs rather than a static site so you might need to add more steps to configure your remote server and your deploy process. Anyways, it shouldn’t be too hard now that you have a boilerplate to start from.<\/p>\n\n\n\n I hope the article was useful, I really hope to hear your opinions in the comments below!<\/p>\n\n\n\n About the Author:<\/b><\/em><\/p>\n\n\n Luciano is a Software Engineer born in 1987, the same year that the Nintendo released \u201cSuper Mario Bros<\/em>\u201d in Europe, which, by chance is his favorite video game!<\/p>\n\n\n\n He is passionate about code, the web, smart apps and everything that’s creative like music, art and design. As web developer, his experience has been mostly with PHP and Symfony2, even if he recently fell in love with Javascript, NodeJS and, Docker. In his (scarce) free time he writes on his personal blog at loige.co<\/a>.<\/p>\n\n\n\n This article is brought to you by Usersnap<\/a>. It\u2019s your central place to organize user feedback and collect bug reports. Report bugs in your browser, and see the bigger picture. Get your 15-day free trial now.<\/a><\/strong><\/em><\/p>\n","protected":false},"excerpt":{"rendered":" With the rise of cheap VPS (Virtual Private Server) services and the increase of complexity in the architecture of new web applications, deployment processes are becoming a very important topic and a skill to master to some extent. Long gone the days when we just needed a cheap hosting service and an FTP access to […]<\/p>\n","protected":false},"author":19,"featured_media":3699,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":true,"inline_featured_image":false,"ub_ctt_via":"","footnotes":""},"categories":[8],"tags":[],"class_list":["post-3694","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development-blog"],"acf":[],"featured_image_src":"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/flightplan-nodejs-web-development-deployment.jpg","author_info":{"display_name":"Luciano Mammino","author_link":"https:\/\/usersnap.com\/blog\/author\/luciano\/"},"yoast_head":"\n
<\/p>\n\n\n\n\n\n\nTry Usersnap for Product Deployment <\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
Setup of the machine<\/h2>\n\n\n\n
\n
\n
Install Nginx (remote)<\/h2>\n\n\n\n
\nsudo apt-get install -y nginx\n<\/pre><\/div>\n\n\n
\nsudo apt-get install -y git\n<\/pre><\/div>\n\n\n
Create a sample website (local)<\/h2>\n\n\n\n
\ngit init\n<\/pre><\/div>\n\n\n
index.html<\/code> and it should look like this:<\/p>\n\n\n\n<html>\n <head>\n <meta charset=\"utf-8\">\n <title>My wonderful website<\/title>\n <link rel=\"stylesheet\" href=\"style.css\">\n <\/head>\n <body>\n <h1>Welcome to my wonderful website<\/h1>\n <p>You will never find another place as cool as this<\/p>\n <\/body>\n<\/html><\/pre>\n\n\n\n
style.css<\/code>:<\/p>\n\n\n\n \n\ncss\n html {\n font-family: sans-serif;\n -ms-text-size-adjust: 100%;\n -webkit-text-size-adjust: 100%;\n }\n\nbody {\n margin: 0;\n }\narticle,\n aside,\n details,\n figcaption,\n figure,\n footer,\n header,\n hgroup,\n main,\n menu,\n nav,\n section,\n summary {\n display: block;\n }\naudio,\n canvas,\n progress,\n video {\n display: inline-block;\n vertical-align: baseline;\n }\naudio:not([controls]) {\n display: none;\n height: 0;\n }\n[hidden],\n template {\n display: none;\n }\na {\n background-color: transparent;\n }\na:active,\n a:hover {\n outline: 0;\n }\nabbr[title] {\n border-bottom: 1px dotted;\n }\nb,\n strong {\n font-weight: bold;\n }\ndfn {\n font-style: italic;\n }\nh1 {\n font-size: 2em;\n margin: 0.67em 0;\n }\nmark {\n background: #ff0;\n color: #000;\n }\nsmall {\n font-size: 80%;\n }\nsub,\n sup {\n font-size: 75%;\n line-height: 0;\n position: relative;\n vertical-align: baseline;\n }\nsup {\n top: -0.5em;\n }\nsub {\n bottom: -0.25em;\n }\nimg {\n border: 0;\n }\nsvg:not(:root) {\n overflow: hidden;\n }\nfigure {\n margin: 1em 40px;\n }\nhr {\n box-sizing: content-box;\n height: 0;\n }\npre {\n overflow: auto;\n }\ncode,\n kbd,\n pre,\n samp {\n font-family: monospace, monospace;\n font-size: 1em;\n }\nbutton,\n input,\n optgroup,\n select,\n textarea {\n color: inherit;\n font: inherit;\n margin: 0;\n }\nbutton {\n overflow: visible;\n }\nbutton,\n select {\n text-transform: none;\n }\nbutton,\n html input[type=\"button\"],\n input[type=\"reset\"],\n input[type=\"submit\"] {\n -webkit-appearance: button;\n cursor: pointer;\n }\nbutton[disabled],\n html input[disabled] {\n cursor: default;\n }\nbutton::-moz-focus-inner,\n input::-moz-focus-inner {\n border: 0;\n padding: 0;\n }\ninput {\n line-height: normal;\n }\ninput[type=\"checkbox\"],\n input[type=\"radio\"] {\n box-sizing: border-box;\n padding: 0;\n }\ninput[type=\"number\"]::-webkit-inner-spin-button,\n input[type=\"number\"]::-webkit-outer-spin-button {\n height: auto;\n }\ninput[type=\"search\"] {\n -webkit-appearance: textfield;\n box-sizing: content-box;\n }\ninput[type=\"search\"]::-webkit-search-cancel-button,\n input[type=\"search\"]::-webkit-search-decoration {\n -webkit-appearance: none;\n }\nfieldset {\n border: 1px solid #c0c0c0;\n margin: 0 2px;\n padding: 0.35em 0.625em 0.75em;\n }\nlegend {\n border: 0;\n padding: 0;\n }\ntextarea {\n overflow: auto;\n }\noptgroup {\n font-weight: bold;\n }\ntable {\n border-collapse: collapse;\n border-spacing: 0;\n }\ndata-language=\"css\">td,\n th {\n padding: 0;\n }\n\/** ------ END NORMALIZE.CSS ------ **\/\nbody h1,\n body p {\n text-align: center;\n }<\/pre>\n\n\n\nindex.html<\/code>.<\/p>\n\n\n![\"website](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/our-website-preview-version-1.png\")
<\/a><\/figure>\n<\/div>\n\n\nTry Usersnap for Product Deployment <\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
\ngit add index.html style.css\n<\/pre><\/div>\n\n\n
\ngit commit -am "first version of the website"\n<\/pre><\/div>\n\n\n
\n
![\"create](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/create-a-new-repository-on-github-flightplan.png\")
<\/a><\/figure>\n<\/div>\n\n\n![\"your](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/your-public-repository-on-github.png\")
<\/a><\/figure>\n<\/div>\n\n\nhttps<\/code> or ssh<\/code> URLs, I recommend to use the former) and get back to your command line console with the following command:<\/p>\n\n\n\ngit remote add origin\n<\/pre><\/div>\n\n\n
\ngit pull origin master\n<\/pre><\/div>\n\n\n
\ngit push --set-upstream origin master\n<\/pre><\/div>\n\n\n
Prepare the deployment scripts (local)<\/h2>\n\n\n\n
\nnpm install -g flightplan\nnpm install flightplan --save-dev\n<\/pre><\/div>\n\n\n
fly<\/code> command) in your system, the second one allows us to use the Flightplan library inside your project.<\/p>\n\n\n\nflightplan.js<\/code>.<\/p>\n\n\n\ndeploy<\/code> and rollback<\/code>.<\/p>\n\n\n\n\n
repo<\/code>: a folder used to download the data (clone) from our git repository. It will allow us to download only the data that changed since the last time we deployed, so it will be really efficient.<\/li>\n\n\n\nversions<\/code>: in this folder we will have different subfolders, one for every deploy.<\/li>\n\n\n\ncurrent<\/code>: a symlink to the last deployed version in the versions<\/code> folder. It’s the folder that will be used to configure Nginx and the only one that will be shown online.<\/li>\n<\/ul>\n\n\n\n\n
repo<\/code> folder is updated to the last version using git pull<\/code><\/li>\n\n\n\nversions<\/code> with a convention name that is given by the current timestamp on the server (this allows us to keep versions easily ordered)<\/li>\n\n\n\ncurrent<\/code> folder<\/li>\n<\/ol>\n\n\n\n\/\/ flightplan.js\nvar plan = require('flightplan');\n\n\/**\n * Remote configuration for \"production\"\n *\/\nplan.target('production', {\n host: 'example.com',\n username: 'someuser',\n password: 'somepassword',\n agent: process.env.SSH_AUTH_SOCK,\n\n webRoot: '\/var\/www\/mywebsite',\n ownerUser: 'www-data',\n repository: 'https:\/\/github.com\/someuser\/example-com.git',\n branchName: 'master',\n maxDeploys: 10\n});\n\n\/**\n * Creates all the necessary folders in the remote and clones the source git repository\n * \n * Usage:\n * > fly setup[:remote]\n *\/\nplan.remote('setup', function(remote) {\n\tremote.hostname();\n\n\tremote.sudo('mkdir -p ' + remote.runtime.webRoot);\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tremote.sudo('mkdir versions');\n\t\tremote.sudo('git clone -b ' + remote.runtime.branchName + ' ' + remote.runtime.repository + ' repo');\n\t});\n});\n\n\/**\n * Deploys a new version of the code pulling it from the git repository\n *\n * Usage:\n * > fly deploy[:remote]\n *\/\nplan.remote('deploy', function(remote) {\n\tremote.hostname();\n\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tremote.sudo('cd repo && git pull');\n\t\tvar command = remote.exec('date +%s.%N');\n\t\tvar versionId = command.stdout.trim();\n\t\tvar versionFolder = 'versions\/' + versionId\n\t\t\n\t\tremote.sudo('cp -R repo ' + versionFolder);\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' ' + versionFolder);\n\t\tremote.sudo('ln -fsn ' + versionFolder + ' current');\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' current');\n\n\t\tif (remote.runtime.maxDeploys > 0) {\n\t\t\tremote.log('Cleaning up old deploys...');\n\t\t\tremote.sudo('rm -rf `ls -1dt versions\/* | tail -n +' + (remote.runtime.maxDeploys+1) + '`');\n\t\t}\n\n\t\tremote.log('Successfully deployied in ' + versionFolder);\n\t\tremote.log('To rollback to the previous version run \"fly rollback:production\"');\n\t});\n});\n\n\/**\n * Rollbacks to the previous deployed version (if any)\n *\n * Usage\n * > fly rollback[:remote]\n *\/\nplan.remote('rollback', function(remote) {\n\tremote.hostname();\n\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tvar command = remote.exec('ls -1dt versions\/* | head -n 2');\n\t\tvar versions = command.stdout.trim().split('\\n');\n\n\t\tif (versions.length < 2) {\n\t\t\treturn remote.log('No version to rollback to');\n\t\t}\n\n\t\tvar lastVersion = versions[0];\n\t\tvar previousVersion = versions[1];\n\n\t\tremote.log('Rolling back from ' + lastVersion + ' to ' + previousVersion);\n\n\t\tremote.sudo('ln -fsn ' + previousVersion + ' current');\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' current');\n\n\t\tremote.sudo('rm -rf ' + lastVersion);\n\t});\n});\n<\/pre>\n\n\n\nThe remote configuration<\/h3>\n\n\n\n
plan.target('production', {\n host: 'example.com',\n username: 'someuser',\n password: 'somepassword',\n agent: process.env.SSH_AUTH_SOCK,\n\n webRoot: '\/var\/www\/mywebsite',\n ownerUser: 'www-data',\n repository: 'https:\/\/github.com\/someuser\/example-com.git',\n branchName: 'master',\n maxDeploys: 10\n});\n<\/pre>\n\n\n\nhost<\/code>, username<\/code>, password<\/code> (probably not required), webRoot<\/code> and repository<\/code>.<\/p>\n\n\n\nThe setup command<\/h3>\n\n\n\n
plan.remote('setup', function(remote) {\n\tremote.hostname();\n\n\tremote.sudo('mkdir -p ' + remote.runtime.webRoot);\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tremote.sudo('mkdir versions');\n\t\tremote.sudo('git clone -b ' + remote.runtime.branchName + ' ' + remote.runtime.repository + ' repo');\n\t});\n});\n<\/pre>\n\n\n\nremote.hostname()<\/code> is a debug function that prints the hostname of the server the script is currently in. I recommend to use it, because if you need to switch to a multi-server environment it will be very useful to follow the output of all the servers.<\/p>\n\n\n\nversions<\/code> folder and we clone our repository into the folder repo<\/code>.<\/p>\n\n\n\nThe deploy command<\/h3>\n\n\n\n
plan.remote('deploy', function(remote) {\n\tremote.hostname();\n\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tremote.sudo('cd repo && git pull');\n\t\tvar command = remote.exec('date +%s.%N');\n\t\tvar versionId = command.stdout.trim();\n\t\tvar versionFolder = 'versions\/' + versionId\n\t\t\n\t\tremote.sudo('cp -R repo ' + versionFolder);\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' ' + versionFolder);\n\t\tremote.sudo('ln -fsn ' + versionFolder + ' current');\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' current');\n\n\t\tif (remote.runtime.maxDeploys > 0) {\n\t\t\tremote.log('Cleaning up old deploys...');\n\t\t\tremote.sudo('rm -rf `ls -1dt versions\/* | tail -n +' + (remote.runtime.maxDeploys+1) + '`');\n\t\t}\n\n\t\tremote.log('Successfully deployied in ' + versionFolder);\n\t\tremote.log('To rollback to the previous version run \"fly rollback:production\"');\n\t});\n});\n<\/pre>\n\n\n\nrepo<\/code> folder pulling all the new stuff from our repository. Then we execute the date +%s.%N<\/code> bash command that prints out the current timestamp in seconds and milliseconds (e.g. 1441459969.874386446<\/code>). This will be the id of our new deploy. At this stage, we simply copy the repo<\/code> folder inside the versions<\/code> folder using the new version id as folder name (e.g. versions\/1441459969.874386446<\/code>). To finish the process we symlink this new folder to the current<\/code> folder. We also take care to assign these files to the user www-data<\/code> so that nginx will be able to read these files.<\/p>\n\n\n\nversions<\/code> directory skipping the first n, where n is the number of deploys that we want to keep.<\/p>\n\n\n\nThe rollback command<\/h3>\n\n\n\n
plan.remote('rollback', function(remote) {\n\tremote.hostname();\n\n\tremote.with('cd ' + remote.runtime.webRoot, function() {\n\t\tvar command = remote.exec('ls -1dt versions\/* | head -n 2');\n\t\tvar versions = command.stdout.trim().split('\\n');\n\n\t\tif (versions.length < 2) {\n\t\t\treturn remote.log('No version to rollback to');\n\t\t}\n\n\t\tvar lastVersion = versions[0];\n\t\tvar previousVersion = versions[1];\n\n\t\tremote.log('Rolling back from ' + lastVersion + ' to ' + previousVersion);\n\n\t\tremote.sudo('ln -fsn ' + previousVersion + ' current');\n\t\tremote.sudo('chown -R ' + remote.runtime.ownerUser + ':' + remote.runtime.ownerUser + ' current');\n\n\t\tremote.sudo('rm -rf ' + lastVersion);\n\t});\n});\n<\/pre>\n\n\n\nversions<\/code> folder. The first one is the newest one, the second is the one we want to rollback to. Then we simply symlink the second to the current<\/code> folder and delete the first one.<\/p>\n\n\n\nMake the first deploy (local)<\/h2>\n\n\n\n
\nfly setup:production\n<\/pre><\/div>\n\n\n
\nfly deploy:production\n<\/pre><\/div>\n\n\n
current<\/code> folder!<\/p>\n\n\n\nConfigure the web server (remote)<\/h2>\n\n\n\n
\nsudo nano \/etc\/nginx\/sites-available\/default\n<\/pre><\/div>\n\n\n
server<\/code> block definition and look for the root<\/code> property. There should be the default nginx page path in there, just replace it with the path of your current<\/code> folder (e.g. root \/var\/www\/mywebsite\/current;<\/code>). Then you have to save the file with ctrl + o<\/code> and exit with ctrl + x<\/code>.<\/p>\n\n\n\n\nsudo service nginx reload\n<\/pre><\/div>\n\n\n
Updating the website (local)<\/h2>\n\n\n\n
<!doctype html>\n<html>\n <head>\n <meta charset=\"utf-8\">\n <title>My wonderful website<\/title>\n <link rel=\"stylesheet\" href=\"css\/style.css\">\n <\/head>\n <body>\n <h1>Welcome to my wonderful website<\/h1>\n <p>You will never find another place as cool as this<\/p>\n <p><img src=\"img\/bridge.jpg\" alt=\"A nice picture of The Bridge\"\/><\/p>\n <\/body>\n<\/html><\/pre>\n\n\n\n
css<\/code> folder! Ok now just add the following block of CSS at the end of our stylesheet to change the background color:<\/p>\n\n\n\ncss\n body {\n background: #97d2fc;\n }\n<\/pre><\/div>\n\n\n![\"website](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/our-website-preview-version-2.png\")
<\/a><\/figure>\n<\/div>\n\n\ngit status<\/code> before committing to have a clear idea of what has changed. That’s the output we should get:<\/p>\n\n\n![\"git-status\"](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/git-status.png\")
<\/a><\/figure>\n<\/div>\n\n\ncss<\/code> so git thinks we deleted it. We also changed our file index.html<\/code>, then there are some new files and folders that we need to add to the repository.<\/p>\n\n\n\nnode_modules<\/code> folder because we don’t want it on our website, it’s just there because it contains all the needed dependencies to run Flightplan on our local machine. Thus, the best approach is to put it onto the git ignore list. To do so we need to create a new file called .gitignore<\/code>:<\/p>\n\n\n\n# .gitignore\nnode_modules\/\n<\/pre>\n\n\n\n
git status<\/code> again you can see that the output changed a bit:<\/p>\n\n\n![\"git-status-2\"](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/git-status-2.png\")
<\/a><\/figure>\n<\/div>\n\n\nnode_modules<\/code> folder disappeared and the new .gitignore<\/code> file is waiting to be added to the repository.<\/p>\n\n\n\n\ngit add --all\n<\/pre><\/div>\n\n\n
git status<\/code> again to see what’s happened:<\/p>\n\n\n![\"git-status-3\"](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/git-status-3.png\")
<\/a><\/figure>\n<\/div>\n\n\ncss<\/code> folder. Great, it seems that we have added all the files that we need and we are now ready to commit<\/strong> the changes to generate a new version in the local repository:<\/p>\n\n\n\ngit commit -am "Added picture and background color"\n<\/pre><\/div>\n\n\n
\ngit push\n<\/pre><\/div>\n\n\n
\nfly deploy:production\n<\/pre><\/div>\n\n\n
Rolling back (local)<\/h2>\n\n\n\n
\n
\nfly rollback:production\n<\/pre><\/div>\n\n\n
Try Usersnap for Product Deployment <\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
Wrapping it up!<\/h2>\n\n\n\n
![\"Luciano](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/08\/luciano-Mammino-300x300.jpg\")
<\/figure>\n<\/div>\n\n\n