{"rowid": 47, "title": "Developing Robust Deployment Procedures", "contents": "Once you have developed your site, how do you make it live on your web hosting? For many years the answer was to log on to your server and upload the files via FTP. Over time most hosts and FTP clients began to support SFTP, ensuring your files were transmitted over a secure connection. The process of deploying a site however remained the same.\n\nThere are issues with deploying a site in this way. You are essentially transferring files one by one to the server without any real management of that transfer. If the transfer fails for some reason, you may end up with a site that is only half updated. It can then be really difficult to work out what hasn\u2019t been replaced or added, especially where you are updating an existing site. If you are updating some third-party software your update may include files that should be removed, but that may not be obvious to you and you risk leaving outdated files littering your file system. Updating using (S)FTP is a fragile process that leaves you open to problems caused by both connectivity and human error. Is there a better way to do this?\n\nYou\u2019ll be glad to know that there is. A modern professional deployment workflow should have you moving away from fragile manual file transfers to deployments linked to code committed into source control.\n\nThe benefits of good practice\n\nYou may never have experienced any major issues while uploading files over FTP, and good FTP clients can help. However, there are other benefits to moving to modern deployment practices.\n\nNo surprises when you launch\n\nIf you are deploying in the way I suggest in this article you should have no surprises when you launch because the code you committed from your local environment should be the same code you deploy \u2013 and to staging if you have a staging server. A missing vital file won\u2019t cause things to start throwing errors on updating the live site.\n\nBeing able to work collaboratively\n\nSource control and good deployment practice makes working with your clients and other developers easy. Deploying first to a staging server means you can show your client updates and then push them live. If you subcontract some part of the work, you can give your subcontractor the ability to deploy to staging, leaving you with the final push to launch, once you know you are happy with the work.\n\nHaving a proper backup of site files with access to them from anywhere\n\nThe process I will outline requires the use of hosted, external source control. This gives you a backup of your latest commit and the ability to clone those files and start working on them from any machine, wherever you are.\n\nBeing able to jump back into a site quickly when the client wants a few changes\n\nWhen doing client work it is common for some work to be handed over, then several months might go by without you needing to update the site. If you don\u2019t have a good process in place, just getting back to work on it may take several hours for what could be only a few hours of work in itself. A solid method for getting your local copy up to date and deploying your changes live can cut that set-up time down to a few minutes.\n\nThe tool chain\n\nIn the rest of this article I assume that your current practice is to deploy your files over (S)FTP, using an FTP client. You would like to move to a more robust method of deployment, but without blowing apart your workflow and spending all Christmas trying to put it back together again. Therefore I\u2019m selecting the most straightforward tools to get you from A to B.\n\nSource control\n\nPerhaps you already use some kind of source control for your sites. Today that is likely to be Git but you might also use Subversion or Mercurial. If you are not using any source control at all then I would suggest you choose Git, and that is what I will be working with in this article.\n\nWhen you work with Git, you always have a local repository. This is where your changes are committed. You also have the option to push those changes to a remote repository; for example, GitHub. You may well have come across GitHub as somewhere you can go to download open source code. However, you can also set up private repositories for sites whose code you don\u2019t want to make publicly accessible.\n\nA hosted Git repository gives you somewhere to push your commits to and deploy from, so it\u2019s a crucial part of our tool chain.\n\nA deployment service\n\nOnce you have your files pushed to a remote repository, you then need a way to deploy them to your staging environment and live server. This is the job of a deployment service.\n\nThis service will connect securely to your hosting, and either automatically (or on the click of a button) transfer files from your Git commit to the hosting server. If files need removing, the service should also do this too, so you can be absolutely sure that your various environments are the same.\n\nTools to choose from\n\nWhat follows are not exhaustive lists, but any of these should allow you to deploy your sites without FTP.\n\nHosted Git repositories\n\n\n\tGitHub\n\tBeanstalk\n\tBitbucket\n\n\nStandalone deployment tools\n\n\n\tDeploy\n\tdploy.io\n\tFTPloy\n\n\nI\u2019ve listed Beanstalk as a hosted Git repository, though it also includes a bundled deployment tool. Dploy.io is a standalone version of that tool just for deployment. In this tutorial I have chosen two separate services to show how everything fits together, and because you may already be using source control. If you are setting up all of this for the first time then using Beanstalk saves having two accounts \u2013 and I can personally recommend them.\n\nPutting it all together\n\nThe steps we are going to work through are:\n\n\n\tGetting your local site into a local Git repository\n\tPushing the files to a hosted repository\n\tConnecting a deployment tool to your web hosting\n\tSetting up a deployment\n\n\nGet your local site into a local Git repository\n\nDownload and install Git for your operating system.\n\nOpen up a Terminal window and tell Git your name using the following command (use the name you will set up on your hosted repository).\n\n> git config --global user.name \"YOUR NAME\"\n\n\nUse the next command to give Git your email address. This should be the address that you will use to sign up for your remote repository.\n\n> git config --global user.email \"YOUR EMAIL ADDRESS\"\n\n\nStaying in the command line, change to the directory where you keep your site files. If your files are in /Users/rachel/Sites/mynicewebite you would type:\n\n> cd /Users/rachel/Sites/mynicewebsite\n\n\nThe next command tells Git that we want to create a new Git repository here.\n\n> git init\n\n\nWe then add our files:\n\n> git add .\n\n\nThen commit the files:\n\n> git commit -m \u201cAdding initial files\u201d\n\n\nThe bit in quotes after -m is a message describing what you are doing with this commit. It\u2019s important to add something useful here to remind yourself later why you made the changes included in the commit.\n\nYour local files are now in a Git repository! However, everything should be just the same as before in terms of working on the files or viewing them in a local web server. The only difference is that you can add and commit changes to this local repository.\n\nWant to know more about Git? There are some excellent resources in a range of formats here.\n\nSetting up a hosted Git repository\n\nI\u2019m going to use Atlassian Bitbucket for my first example as they offer a free hosted and private repository.\n\nCreate an account on Bitbucket. Then create a new empty repository and give it a name that will identify the repository easily.\n\nClick Getting Started and under Command Line select \u201cI have an existing project\u201d. This will give you a set of instructions to run on the command line. The first instruction is just to change into your working directory as we did before. We then add a remote repository, and run two commands to push everything up to Bitbucket.\n\ncd /path/to/my/repo\ngit remote add origin https://myuser@bitbucket.org/myname/24ways-tutorial.git\ngit push -u origin --all \ngit push -u origin --tags \n\n\nWhen you run the push command you will be asked for the password that you set for Bitbucket. Having entered that, you should be able to view the files of your site on Bitbucket by selecting the navigation option Source in the sidebar.\n\nYou will also be able to see commits. When we initially committed our files locally we added the message \u201cAdding initial files\u201d. If you select Commits from the sidebar you\u2019ll see we have one commit, with the message we set locally. You can imagine how useful this becomes when you can look back and see why you made certain changes to a project that perhaps you haven\u2019t worked on for six months.\n\nBefore working on your site locally you should run:\n\n> git pull\n\n\nin your working directory to make sure you have all of the most up-to-date files. This is especially important if someone else might work on them, or you just use multiple machines.\n\nYou then make your changes and add any changed or modified files, for example:\n\n> git add index.php\n\n\nCommit the change locally:\n\n> git commit -m \u201cupdated the homepage\u201d\n\n\nThen push it to Bitbucket:\n\n> git push origin master\n\n\nIf you want to work on your files on a different computer you clone them using the following command:\n\n> git clone https://myuser@bitbucket.org/myname/24ways-tutorial.git\n\n\nYou then have a copy of your files that is already a Git repository with the Bitbucket repository set up as a remote, so you are all ready to start work.\n\nConnecting a deployment tool to your repository and web hosting\n\nThe next step is deploying files. I have chosen to use a deployment tool called Deploy as it has support for Bitbucket. It does have a monthly charge \u2013 but offers a free account for open source projects.\n\nSign up for your account then log in and create your first project. Select Create an empty project. Under Configure Repository Details choose Bitbucket and enter your username and password.\n\nIf Deploy can connect, it will show you your list of projects. Select the one you want.\n\nThe next screen is Add New Server and here you need to configure the server that you want to deploy to. You might set up more than one server per project. In an ideal world you would deploy to a staging server for your client preview changes and then deploy once everything is signed off. For now I\u2019ll assume you just want to set up your live site.\n\nGive the server a name; I usually use Production for the live web server. Then choose the protocol to connect with. Unless your host really does not support SFTP (which is pretty rare) I would choose that instead of FTP.\n\nYou now add the same details your host gave you to log in with your SFTP client, including the username and password. The Path on server should be where your files are on the server. When you log in with an SFTP client and you get put in the directory above public_html then you should just be able to add public_html here.\n\nOnce your server is configured you can deploy. Click Deploy now and choose the server you just set up. Then choose the last commit (which will probably be selected for you) and click Preview deployment. You will then get a preview of which files will change if you run the deployment: the files that will be added and any that will be removed. At the very top of that screen you should see the commit message you entered right back when you initially committed your files locally.\n\nIf all looks good, run the deployment.\n\nYou have taken the first steps to a more consistent and robust way of deploying your websites. It might seem like quite a few steps at first, but you will very soon come to realise how much easier deploying a live site is through this process.\n\nYour new procedure step by step\n\n\n\tEdit your files locally as before, testing them through a web server on your own computer.\n\tCommit your changes to your local Git repository.\n\tPush changes to the remote repository.\n\tLog into the deployment service.\n\tHit the Deploy now button.\n\tPreview the changes.\n\tRun the deployment and then check your live site.\n\n\nTaking it further\n\nI have tried to keep things simple in this article because so often, once you start to improve processes, it is easy to get bogged down in all the possible complexities. If you move from deploying with an FTP client to working in the way I have outlined above, you\u2019ve taken a great step forward in creating more robust processes. You can continue to improve your procedures from this point.\n\nStaging servers for client preview\n\nWhen we added our server we could have added an additional server to use as a staging server for clients to preview their site on. This is a great use of a cheap VPS server, for example. You can set each client up with a subdomain \u2013 clientname.yourcompany.com \u2013 and this becomes the place where they can view changes before you deploy them.\n\nIn that case you might deploy to the staging server, let the client check it out and then go back and deploy the same commit to the live server.\n\nUsing Git branches\n\nAs you become more familiar with using Git, and especially if you start working with other people, you might need to start developing using branches. You can then have a staging branch that deploys to staging and a production branch that is always a snapshot of what has been pushed to production. This guide from Beanstalk explains how this works.\n\nAutomatic deployment to staging\n\nI wouldn\u2019t suggest doing automatic deployment to the live site. It\u2019s worth having someone on hand hitting the button and checking that everything worked nicely. If you have configured a staging server, however, you can set it up to deploy the changes each time a commit is pushed to it.\n\nIf you use Bitbucket and Deploy you would create a deployment hook on Bitbucket to post to a URL on Deploy when a push happens to deploy the code. This can save you a few steps when you are just testing out changes. Even if you have made lots of changes to the staging deployment, the commit that you push live will include them all, so you can do that manually once you are happy with how things look in staging.\n\nFurther Reading\n\n\n\tThe tutorials from Git Client Tower, already mentioned in this article, are a great place to start if you are new to Git.\n\tA presentation from Liam Dempsey showing how to use the GitHub App to connect to Bitbucket\n\tTry Git from Code School\n\tThe Git Workbook a self study guide to Git from Lorna Mitchell\n\n\nGet set up for the new year\n\nI love to start the New Year with a clean slate and improved processes. If you are still wrangling files with FTP then this is one thing you could tick off your list to save you time and energy in 2015. Post to the comments if you have suggestions of tools or ideas for ways to enhance this type of set-up for those who have already taken the first steps.", "year": "2014", "author": "Rachel Andrew", "author_slug": "rachelandrew", "published": "2014-12-04T00:00:00+00:00", "url": "https://24ways.org/2014/developing-robust-deployment-procedures/", "topic": "process"}