Skip to content
Permalink
04246d7503
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
 
 
Cannot retrieve contributors at this time

DevOps

In this lab you will learn how to deploy your app to a cloud server and how to set up a complete devops build chain. For this tutorial you will need to have an account on the GitLab server as we will be learning how to use the GitLab CI continuous integration tools. (Note that GitHub has recently introduced a rival service called GitHub Actions however at the time of writing this was still in Beta).

Create an account using your University email address and log in. Create an empty private repository called devops and make a note of the git clone URL.

You should now clone the template-dynamic-website repository (the original template, not the one you have been using for your assignment) into a temporary location on your computer.

git clone https://github.coventry.ac.uk/web/template-dynamic-websites.git temp

Once cloned you need to mirror push to the empty gitlab repository.

cd temp/ && git push --mirror xxx

If you get an error at this point you need to use the following technique:

$ git remote set-url origin https://gitlab.com/xxx/devops.git
$ git push origin master

Change xxx to your username.

Now delete the temporary local repository.

cd .. && rm -rf temp

Now you can clone the repository from the GitLab repository.

1 Deploying to the Cloud

In this task you will learn how to deploy apps to the Heroku cloud.

Create yourself an account on the Heroku website and verify the account is live by logging into the website. Whilst you can create new apps from this screen we will be doing this through the Terminal window.

1.1 Configuring the App

There are a few changes that need to be made to the code before you attempt to deploy it to the cloud server. The first is to understand that the cloud service will determine which port your app will need to run on which is mapped to the URL. To enable this, the remote server instance will have an environment variable called PORT set and you need to check for this before setting the port the app will use. If you study the index.js file in the template-dynamic-website template you will find the following two lines of code:

const defaultPort = 8080
const port = process.env.PORT || defaultPort

This defines a default port for the app to run on. The second line assigns the value in the PORT environment variable to the port variable and, if this is not available assigns the default port.

The second issue is that the cloud service will automatically be installing the module dependencies with no intervention from you. This means that these must all be listed in the dependencies key in your package manifest package.json.

1.2 Configuring the Server

We will be interacting with Heroku using a command-line utility. Open up the Terminal window and install it using the detailed instructions on their website.

Then you need to log into Heroku from the command-line to exchange SSH keys.

$ heroku login
  Enter your Heroku credentials.
    Email: marktyers@gmail.com     
    Password (typing will be hidden):
  Authentication successful.

Next we need to create our remote app on the cloud, replacing <appname> with the name you chose for your app (this should be your university username followed by -test, for example doej-test. If you don't specify a name parameter one will be automatically generated for you.

$ heroku create <appname>
  Creating <appname>... done, stack is cedar-14
  https://<appname>.herokuapp.com/ | https://git.heroku.com/<appname>.git
  Git remote heroku added

If you check your git remotes you should find that heroku has added a second one.

git remote -v
heroku  https://git.heroku.com/<appname>.git (fetch)
heroku  https://git.heroku.com/<appname>.git (push)
origin  https://github.coventry.ac.uk/xxx/xxx.git (fetch)
origin  https://github.coventry.ac.uk/xxx/xxx.git (push)

1.3 Deploying to Heroku

Assuming the git working directory is clean, deploying is as simple as pushing to the heroku remote instead of the origin remote. To push to the Heroku server:

$ git push heroku master

This will push the latest commits to the Heroku server. Once this is completed, the server will be stopped and then restarted using the information contained in the config file. You should be able to view the progress by checking the messages appearing in the terminal window.

The first time the app gets deployed we need to start an app instance running.

$ heroku ps:scale web=1

You should now be able to view your application on the server. Checking the Logs Heroku keeps a detailed log which can be viewed using the heroku logs command. By passing the tail flag we only see the last 10 lines. For example if you view the URL, the following gets added to the log file.

heroku logs --tail
2015-04-18T18:34:57.199901+00:00 heroku[router]: at=info method=GET path="/" host=marktyers.herokuapp.com request_id=c98d5ee5-afb8-47fd-bf78-05c2ac3d3713 fwd="90.244.82.220" dyno=web.1 connect=2ms service=8ms status=200 bytes=124

2 Continuous Integration

Continuous integration is the process of regularly merging code changes into the central repository. For this to work all code must be regularly checked for issues using a range of automated tools. As of the time of writing GitHub have an integrated CI tool called Github Actions however this is still in beta. For this lab you will be using the CI tools that are built into GitLab which is why you have already mirrored the test code to a repository on the GitLab server.

Committing and pushing to trigger the workflow.

3 Continuous Delivery

Once you have mastered the deployment process and configuring your CI pipeline you will want to implement a full CD workflow. This will require you to automate the deployment to one (or more) cloud servers. To achieve this you will need to add additional stages to your CI build to:

  1. Deploy to a test server.
  2. Run a suite of acceptance tests.
  3. Deploy to the live server.

Whilst you will need to spend time configuring the build and ensuring that the correct stages of the pipeline run on the correct branches you will find the following snippet helpful:

deploy-staging-server:
  stage: staging-server
  script:
  - apt-get update -qy
  - apt-get install -y ruby ruby-dev rubygems-integration
  - gem install dpl
  - dpl --provider=heroku --app=<YOUR APP NAME> --api-key=<YOUR KEY HERE>
  only:
  - master