Deploying Code to a Web Server

The most common type of application nowadays is a web application. Even applications with locally installed interfaces (like mobile apps from the Apple App Store or the Google Play Store), typically rely on extensive server-side code to support the application. Either way, the application is going to need code uploaded to a server in order to work. What are the options for moving code from a local development environment to a production server?

The most primitive approach to server-side code deployment is simply to create and edit all files on the server itself. This is generally not recommended. Although it may seem quick and easy to line edit files directly on the server, there are all kinds of risks associated with this process.

  • For one thing, server-hosted text editors (like vim or nano) are relatively primitive and offer none of the advantages of an integrated development environment.
  • What's more, typos that go directly to files on the server are full of dangers! On a production website, any user can immediately see your blunders. Also, you might make changes that are not so easy to undo.
  • If multiple developers are contributing to the site, each of them can overwrite the work of the others. There is nothing about server-side text editing that tracks changes, provides for rollbacks, or supplies collaboration features.

So, use server-side text edits at your own peril!

 

Once we agree that developing code on a local machine makes more sense than server-side editing, there still remains the question of what is the best way to transfer files to the server. The most direct approach is File Transfer Protocol (FTP). FTP is one of the oldest services on the Internet and as such, it is widely supported. [To get an idea of how to set up an FTP server, see this article]. You can launch an FTP session from your local command line or from FTP client software like Filezilla. FTP runs on TCP ports 20 and 21, so you will need both those ports open on both the client-side and the server-side firewalls. It's possible to set up FTP for anonymous login, but unless you are crowdsourcing your application to random Internet users, configuring an FTP username and password is a better idea. Still, even if your password is relatively complex, with FTP all files traverse the network in cleartext. If your content is sensitive, this may be a problem. With IT security becoming an ever-greater concern, clear text protocols like FTP are losing favor compared to more secure encrypted protocols like SFTP.

SFTP stands for Secure File Transfer Protocol. SFTP runs over TCP port 22, the same as SSH. SSH provides encrypted remote console sessions and it requires a public or private key pair member on each side of the network connection. SFTP uses this same approach. So, if you have set up a public/private key pair for SSH and opened port 22 on either side of the connections, using SFTP is relatively simple. Like FTP, you can run SFTP either from a command line or from a client like WinSCP. 

 

A common drawback for both FTP and SFTP is that like for server-side editing, there are no file-tracking, management, or collaboration features built into the system. If you delete a bunch of files from your server accidentally, it's all on you to figure out what files to restore from backup (assuming you have backup).  Likewise, if you overwrite your partner's latest changes with an SFTP upload, the fact that your work-ruining blunder traveled over a secure network pathway will provide little consolation to your partner who lost the work! Pure file transfer works fine for tiny websites managed by single developers. Once larger development teams come into play, it's time to step up to Software Version Control (SVC).

Git is an example of SVC. Most of this class has been about learning Git. There are other SVC options like Subversion or Mercurial. SVC systems in general track changes, allow for rollbacks, and provide team collaboration features like comments, approvals, or code review. As far as network transmission is concerned, Git offers multiple options including HTTPS or SSH. During this quarter, we have studied a variety of Git commands suitable for managing data transmission between client and server. These include:

  • git pull (pull an update to the server)
  • git push (push an update to the server) 
  • git clone (copy an entire repository from one side to the other)

Git also has a feature called webhooks that provides for sending automated notifications of changes to a repository to repo owners or collaborators over the Internet. 

Moving files over the network to the server is one important step for deploying a web app or any other server-side code, but it's not the only management step required. For one thing, your server-side needs to be running a server! Web servers like Apache or nginx are widely available for most platforms. Configuration options and practices for these servers could take their own dedicated full-quarter course, so we'll stick to the most basic ideas here. Web servers run as processes on a host operating system. They create TCP/IP sockets for network traffic, typically on TCP port 80 (for HTTP) and TCP port 443 (for HTTPS). The server will need these ports open on the firewall. Web clients (like browsers) use random port numbers, so no special firewall rules are needed there. HyperText Transfer Protocol (HTTP) is a request/response protocol in which clients request web pages (usually HTML files). The server replies by sending these pages. This only works, though, if the web pages are stored correctly on the server. For any web server, there will be a special directory called "webroot," which is the first place an HTTP request will go looking for files. The webroot is almost never the root directory of the server itself. Instead, it's a special subdirectory set up for web requests. For Apache on Linux, for example, the webroot is normally in:

  • "/var/www/html/"

Contrast this with:

  • "/" (the root directory)

and 

  • "/root" (the root user's home directory)

Configuring a web server to use either "/" or "/root" as webroot would be terrible from a security standpoint and absolutely not recommended! Speaking of security, the whole point of a web server is to serve up files on request. For this to work, the files and the directories they reside in need to have the correct permissions. Too loose, and anyone can change the files. Too tight, and no one can read the files. On a Linux system, a common file permission setting for web pages is 644 or rw_r__r__. That means the owner can read and write to the pages, and everyone else gets read access only. After a file is uploaded to a Linux system, a command like

chmod 644 myNewPage.html

can make the page available to web browsers on the Internet. 

Listen to an audio transcript of this page Links to an external site.