Deploying

DeploymentHostingGitHub PagesStatic Hosting

Introduction

So far we have worked with a local development server, in order to view our work. Although this is the default environment for most software development activities, this environment cannot be safely shared with the general public. A server is simply a computer without a screen, and must be carefully secured before it can be safely exposed to the internet. In the past, deployment required an entire speciality of software engineers and a great amount of knowledge. Over time, hosting has been simplified to the point where even a new developer can quickly deploy a website to the internet.

Hosting Theory

Every website or web application that we interact with is, underneath it all, simply a folder full of text files sitting on a computer hard drive somewhere in the world. This includes massive services such as Google, Bing or Spotify - although these are so complicated that they must be split up into many applications and spread across an incredibly complex network of computers.

Hosting Options

Although “hosting” always means the same thing in the context of web development, there are many different companies that offer various different types of hosting. The purpose of this lesson is not to explore all of the different options, but to introduce and contextualise the most common options for a new developer.

Your PC

We could, in theory, host a web application directly from our personal computer by exposing your local development server directly to the internet. Putting aside the immediate security concerns this would introduce, there are some other practical drawbacks:

  • The PC must remain on, forever. As soon as it switches off, users will lose access to the website.
  • The PC must be connected to the internet, forever. As soon as the internet connection drops, users will lose access to the website.
  • The PC must have a static IP address. This is a special address that never changes, and is required for users to be able to find the website. Most home internet connections do not have a static IP address, and instead use a dynamic IP address that changes every time the router is restarted.
  • The PC must be powerful enough to handle the traffic. If the website becomes popular, the PC may not be able to handle the number of requests it receives. If the PC is not powerful enough, it will lock up and become slow while you are trying to use it.

As you can see, there is really no good reason to use a personal computer for the purposes of serving any kind of content to the public. As a strict rule, we always use a dedicated and professional web host to serve our content to the public.

Dynamic Hosting

Dynamic hosting is the most common type of hosting, and is used by most complex web applications. A dynamic host allows for a website to be managed, updated and changed without having to manually edit the files on the server. This is achieved by using a database to store the content of the website, and a server-side programming language to dynamically generate the HTML that is sent to the user. WordPress is perhaps the most famous of these types of platforms, but there are many others. Common backend languages include PHP, NodeJS, Python and Ruby.

Static Hosting

Static hosting is the simplest, cheapest and easiest type of hosting to learn. Static hosting is used for websites that do not need to be updated frequently, and do not need to be managed by a content management system. In recent years, the move towards front-end frameworks such as React, Vue or Svelte has led to a rise in the popularity of static hosting. These frameworks allow us to do much more with less hosting resources, leading to more efficient and lower cost hosting.

In fact, static hosting has become so cheap that it is now free to host static content on a high quality, professional hosting service. This is the type of hosting we will be using for our projects. Netlify is the most popular choice for static hosting, but there are many others such as Vercel, GitHub Pages and Firebase. In this lesson we will be using GitHub Pages in order to keep all of our resources with the same platform.

Setting up GitHub Pages

In order to setup GitHub Pages for a project, we must visit the project repository on GitHub and follow these steps:

  1. Click on the “Settings” tab.
  2. In the sidebar, look for the “Pages” section and click on it.
  3. Under “Source”, select the branch you want to use for deployment. This is usually the main branch.
  4. Save your changes.
  5. Wait for the deployment to complete. This can take up to 5 minutes.
  6. View the provided link to see your deployed project.

GitHub Actions

This is covered in detail later in the program, and you will not need to use this for any assignment or examination until that point. We will always deploy from the main branch, and avoid these settings for now.

Domain Names

There are four options for identifying a project on the internet:

  • Raw IP, instead of using a domain name you could simply use the IP address of the server. This is not recommended, as IP addresses are difficult to remember and can change without warning. Example: http://123.123.123.111/about.html
  • Custom Domain, this is the most common option. Custom domains can be purchased form a domain registrar, and then pointed to the hosting provider. Example: http://www.example.com/about.html
  • Custom Subdomain, this is a less common option. We can create an infinite number of subdomains on a domain that we already own, and point that subdomain to the hosting provider. Example: http://about.example.com
  • Allocated Subdomain, this is the least common option. Some hosting providers will allow you to use a subdomain of their own domain. Example: http://username.github.io/example/about.html

Purchasing a domain name is not necessary to complete any of the projects in this course, but it is a good idea to do so if you are planning to use your projects in a professional portfolio. If you do not want to purchase a domain name, you can use the allocated subdomain option.

Your Domain Name

It makes sense for a front end web developer to have a public portfolio, especially towards the end of the program. Consider purchasing a domain name that can be used to represent yourself in this way, perhaps with multiple subdomains:

txt 
	cv.example-person.no
	portfolio.example-person.no
	html-css.example-person.no
	project-exam.example-person.no

While this is not strictly required, it helps to keep your work organised and easy to access.

Using an Allocated Subdomain

When using an automatically allocated subdomain, the domain name will be different depending on the hosting provider. For GitHub Pages, the domain name will be in the format http://username.github.io/example. For Netlify, the domain name will be in the format http://example.netlify.app. For Vercel, the domain name will be in the format http://example.vercel.app. For Firebase, the domain name will be in the format http://example.web.app.

When using GitHub pages, we may run into issues with 404 errors for images or CSS resources. These errors can be resolved by updating links, and requires a good understanding of how routing works. Using root / relative links may create issues, and using ./ or ../ relative links is most likely to work.

Creating a Custom Subdomain

If you have purchased a domain name, you can create a custom subdomain for your project. This can be done by following the official instructions here: Configuring a Subdomain.

These instructions can be difficult to access as a beginner, so we can break this process down into steps:

How to Configure a Subdomain on GitHub Pages for Beginners

  1. Go to GitHub and open the repository where your project site is located.
  2. Under your repository name, click on the “Settings” tab.
  3. In the sidebar, look for the “Code and automation” section and click on “Pages.”
  4. Under “Custom domain,” type in the subdomain you want to use (e.g., html-css-ca.example-person.no) and click “Save.”
  5. Go to your Domain registrar’s website and log in to your account.
  6. Find the DNS settings for your domain name.
  7. Create a CNAME record that points your subdomain to your GitHub Pages default domain. For example, if your GitHub username is example-person, the CNAME record should point html-css-ca.example-person.no to example-person.github.io..
  8. Wait for the DNS changes to propagate. This can take up to 24 hours but is commonly done in an hour or so.
  9. Go back to your GitHub Pages settings and refresh the page. You should see a green checkmark next to your custom domain name.
  10. Visit your subdomain in a browser. You should see your GitHub Pages site.

Making Changes

Once a project has been hosted on GitHub Pages, we can make changes to the project and deploy those changes to the internet. This is done by pushing the changes to the main branch on GitHub. The deployment will be triggered automatically, and the changes will be visible on the internet within a few minutes.

Considering that each change to this branch will now become available to the public, it is important to ensure that the changes are ready to be deployed. This means that we should only deploy changes that are complete, and have been tested thoroughly. We should also ensure that the changes do not break any existing functionality.

In order to control this process, developers use Pull Requests to manage batches of changes that are ready to be deployed. This is covered in detail later in the program, and you will not need to use this for any assignment or examination until that point. If you would like to learn more about branching and Pull Requests - this knowledge will serve you well later on.

Post Deployment

After each deployment, it is crucial to perform careful testing to ensure that the deployed site is working as expected. Sometimes, a change on our local machine works fine - but does not work on the server. Assuming that everything will go fine after a deployment is not only a sure fire way to be embarrassed in front of a boss or client, but could cost you a CA or exam delivery.

With this in mind, it is recommended to run through the following steps after a deployment:

  1. Open the deployed site in a browser.
  2. Test the site on a mobile device, making notes of any visual issues.
  3. Test the site on a tablet device or small browser window, making notes of any visual issues.
  4. Test the site on a large device such as a smart TV, making notes of any visual issues.
  5. Check for broken images, CSS files or other remote resources by keeping the browser console open and noting errors.
  6. Test all links on the site, making notes of any broken links.
  7. Test all buttons, forms and other interactive elements on the site, making notes of any broken functionality.
  8. Using your notes, fix any issues that you have found and re-deploy.
  9. Go back to 1.

Frequent, careful testing is a key skill for a developer. Later in the program we will learn how to automate this process “from end to end”.