Skip to content
Permalink
master
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](https://gitlab.com) 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](https://github.com/features/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.
```shell
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.
```shell
cd temp/ && git push --mirror xxx
```
If you get an error at this point you need to use the following technique:
```shell
$ 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.
```shell
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:
```javascript
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](https://devcenter.heroku.com/articles/heroku-cli) on their website.
Then you need to log into Heroku from the command-line to exchange SSH keys.
```shell
$ 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.
```shell
$ 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.
```shell
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:
```shell
$ 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.
```shell
$ 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.
```shell
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:
```yaml
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
```