- Install a Linux distribution
- You may choose to create a virtual machine for this (or right on hardware), you may already have this and you also may choose to create a new one.
- You can choose whichever you like, there are many to choose from.
- One common distribution used on campus by many students is Ubuntu Desktop of which you can choose stable 20.04 Focal Fossa. See more info about Ubuntu release cycles (Links to an external site.).
- Install support for your development environment. This should include:
- git installed for pushing to your GitHub repository.
- Setup web deployment. You can choose a classic LAMP stack or go with another option like Node.js. Your choice really here if you run your web setup on a standard of ports 443/80 or 8443/8080
- Setup your first test use of Cron on your server. You will need this to automate pulls from your GitHub repository in DevOps part 3, GitHub, SSH and keys (Individual) and DevOps part 4, JUnit Automation (Individual)
- Ensure that you have your GitHub account.
- Ensure that you have a repository created for testing. I recommend some form of web content, but you can choose your content for the testing. You should put this in the root of your web server that you created in DevOps part 2, Linux Server Setup (Individual)
- Setup your GitHub two-factor authentication.
- Setup your SSH keys (Links to an external site.) so that you are able to connect to GitHub repositories using ssh (Links to an external site.).
- Ensure that you can do a git clone (use ssh) to your server from your repository. You should do this.
- Make changes to your repository (you can do this any method including via the GitHub site).
- Ensure that you can update your server copy with a simple "git pull origin master" at the command line from the directory where you have pulled your data.
- Does the webpage update if you reload that this code sits in?
- Automate those updates using what you learned about cron in DevOps part 2, Linux Server Setup (Individual). How often should you update? How do you ensure (and you should do this) that you do not end up with two copies of your update script running at the same time?
- Ensure that you can use your JUnit (or other unit testing) via the command line (Links to an external site.).
- Setup a status page that shows the status of your build. It should be pulling from your GitHub repository on a schedule (see DevOps part 2, Linux Server Setup (Individual)), running the unit test and then updating the status page based on web site based on build success or failure. Get creative here.
- How could you update the README page on your repository to reflect the build status using this setup?
- Reflect on what you already knew and what you learned in this exercise.
- Much of this is simpler with already existing frameworks and services. Find ones would replace much of this work for you. What are the advantages and disadvantages of this?
- Have you gained some appreciation for the concept of "excise tasks" and the value of those in our workplace that perform those as part of a team?