DevOps Workshop Part 1
0 likes100 views
The document provides an overview of a DevOps workshop that teaches DevOps concepts and practices including CI/CD. The workshop agenda covers What is DevOps?, CI/CD, implementing CI/CD with GitHub Actions, and deploying a React/Firebase project. Attendees will learn how to automate testing and deployment of their React app via a GitHub Actions workflow that is triggered on pushes to main and deploys the built app to Firebase hosting. By the end of the workshop, attendees will have hands-on experience creating a CI/CD pipeline for their own project.
Ad
More Related Content
Similar to DevOps Workshop Part 1 (20)
More from GDSC UofT Mississauga (20)
![Full Stack React Workshop [CSSC x GDSC]](https://cdn.slidesharecdn.com/ss_thumbnails/fullstackreactworkshopcsscxgdsc-230221003415-b512c1cf-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
Ad
DevOps Workshop Part 1
- 1. DevOps Workshop Part 2 coming soon!
- 2. Todayʼs Agenda ● What is DevOps? ● What is CI/CD? ● How to implement CI/CD using GitHub Actions? ● A brief introduction to Firebase ● And much more!
- 3. By the end of it, you’ll have your own “DevOps-ified “ React/ Firebase project! You can then edit the React App’s code and turn it into your own thing (ex. Personal website, etc.)
- 4. So, what is DevOps? ● Set of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity ● Primarily through automating and streamlining development and infrastructure management processes
- 5. Benefits of DevOps ● Speed/Agility ● Rapid Deployment ● Quality and reliability ● Improved Collaboration ● And much more!
- 6. DevOps Best Practices ● Continuous Integration ● Continuous Delivery ● Microservices ● Infrastructure as Code ● Monitoring and Logging ● Communication and Collaboration
- 7. DevOps Best Practices ● Continuous Integration ● Continuous Delivery ● Microservices ● Infrastructure as Code ● Monitoring and Logging ● Communication and Collaboration Note: Continuous Integration + Continuous Delivery referred to as “CI/CD”
- 8. ● Pipeline: set of automated processes ○ Ex. Automatically testing your code, and then automatically deploying them
- 9. Example Your banking App $ git push Does app display correct output for account balance? yes Deploy the changes internet (whether that be on your own servers,Google’s Firebase servers, etc) How do we automate this? Aka how do we implement CI/CD for our app? Testing
- 10. How do we automate this? ● We call this process of automating particular parts of software development “continuous integration, continuous delivery, and continuous deployment (CI/CD for short)”
- 11. How do we automate this? ● Software/tools that allow us to implement CI/CD are: ○ GitHub Actions ○ Travis CI ○ Jenkins ○ etc.
- 12. GitHub Actions ● Service created by GitHub that we can use for CI/CD ● GitHub Actions makes it easy to automate all your software workflows ● You can configure a GitHub Actions workflow to be triggered when something happens in your repository ○ Ex. on a push to the repo, on a merge between two branches, on every pull request etc.
- 13. How Github Actions work 1. Create a file that tells GitHub Actions what to do a. needs to be a .yaml file that is placed in the .github/workflows/ directory b. This file needs to conforms to the specific GitHub Action syntax 2. Specify when we want this script to run (ex. On a push to the main branch of your GitHub repository) 3. Specify what you want the script to do when it is triggered 4. When this trigger is set off, GitHub will run this script on their servers!
- 14. How Github Actions work (lower level) 1. We create a .github/workflows/<something>.yaml in the root level of our github repository 2. We specify when we want this script to run (ex. On a push to the main branch) 3. We can optionally define in some environment variables that will be available to use by the server running the script 4. We specify what the script should do 5. This script then gets run on one of GitHub’s many servers
- 18. You can name this job whatever you want
- 19. You can name this job whatever you want
- 20. Define these ‘secrets’ in your GitHub repos Settings -> Secrets Secrets are basically encrypted variables that you can define for your github actions repo so you don’t have to hardcode them in to your (possibly) publicly viewable script
- 21. Define these ‘secrets’ in your GitHub repos Settings -> Secrets See here for details Secrets are basically encrypted variables that you can define for your github actions repo so you don’t have to hardcode them in to your (possibly) publicly viewable script
- 22. Define these ‘secrets’ in your GitHub repos Settings -> Secrets
- 23. ● This is admittedly a pretty useless example of a GitHub action (just writing some values to stdout) ● Later in the workshop we will see how we can ‘build’ a React app , test it, and deploy it to Firebase.
- 24. Testing ● One action that is often included in CI/CD is automated testing ● Testing is important important ○ Frequent testing of your codebase allows your program to be less prone to errors ○ This allows checking to make sure a new block of code doesn’t break the previously written code ○ etc
- 25. Manual Testing ● This is done by a person (tester) without using any automated tools ● This is often very expensive and time consuming for a company ● Prone to human errors ● Any new application must be manually tested before its testing can be automated.
- 26. Automated Testing ● Done by a computer ● Extremely inexpensive and quick to run ■ Development of good tests suites can take time though! ● Might not be able to test certain things as well as a person though ■ Ex. If your website has a lot of animations and want to test to see if all of them look ok, you’re likely better off with manual testing
- 27. Automated Testing: Types of Tests ● Unit Tests ○ Testing small ‘units’ of an application individually ○ For example, testing individual methods, functions, components or modules ● Integration tests ○ Testing to see if your modules/components/functions/etc work together ● Several other types of tests can be found here
- 28. Examples of each ● both doors likely work individually (would be verified by a unit test) ● but they clearly do not work together (would be verified by a integration test)
- 29. Unit vs Integration Example
- 30. Letʼs see how tests look like in React!
- 32. Wait, whatʼs Firebase? ● Firebase is a platform developed by Google for creating mobile and web applications. ● It abstracts away a lot of backend development for you ○ ex. you can get a website up and running with a single click without having to do any back-end work ○ simplifies setting up and connecting your app to a database (called Firestore) ○ Simplifies Authentication ○ And much more!
- 33. Firebase intro continued.. ● We will just be focusing on the “web hosting” portion of Firebase for this workshop ● Please let us know if you’d like to see a dedicated workshop on Firebase! ● Let’s create a new firebase project!
- 34. Deploying React app on Firebase (~3 min) 1. FORK this repository (aka created your own copy of it) and clone this forked repo onto your computer. 2. cd <name of this directory> 3. npm install firebase-tools -g 4. firebase login a. Logs you in with your google account using the CLI 5. firebase init a. Will prompt you with several questions (I’ll show you what to select in next slide)
- 35. Answer the firebase init prompts as follows: ● Which Firebase CLI features do you want to set up for this folder? → Configure and deploy Firebase Hosting sites ● What project do you want to use? -> Use existing ○ And then select the project you just created ● What to use as public directory? → build ● Configure as single page app? -> Yes ● Set up automatic builds and deploys with GitHub? -> No ● Overwrite index.html? -> No Firebase-ify an existing React project
- 36. build Firebase-ify an existing React project
- 37. Firebase init result ○ You should see that firebase created some new files and directories ○ firebase json: ■ where you can specify various hosting rules for your app (ex. where should firebase find all the files it will server users?) ○ .firebaserc: ■ - a file that contains info to identify your firebase project
- 38. Firebase init result ● To serve your project locally (through a web server running locally that listens to port 5000 by default) ● npm install && npm run build (if you haven’t already) ● Followed by, firebase serve ● Note: only for windows users, please remove the “CI=false &&” part from line 17 of package.json if you want to run it locally. IMPORTANT: add it back once you are ready to setup github actions for it. ● Note: if you get an 403 error when visiting localhost:5000, Do this instead: firebase serve -o 0.0.0.0
- 39. Letʼs deploy to firebase ➔ Just execute the command (assuming you have ran npm run build beforehand): → firebase deploy ● URL of your app will be outputted to you ● App is now live on the internet! ● Really easy, right?
- 40. Letʼs automate this with GitHub Actions! Let’s head over to my computer! For those revisiting the slides afterwards, the finished GitHub actions file is here
- 41. Letʼs deploy to firebase (~1min) ● First thing we need is a “Firebase CI Token” to basically authorize GitHub Actions to be able to interact with our Firebase Project ● Run the following command in your terminal: ● firebase login:ci This will prompt you to sign in using your browser and if successful it will output a token in your terminal
- 42. Deploying to firebase cntd. (~2min) ● Follow these steps to add this token as a ‘secret’ in your repository ○ Just think of a ‘secret’ as a safe, secure variable that your GitHub actions script can use ● To follow along with me (or to get the finished GitHub Action file working), name this secret DEVOPS_1_FIREBASE_TOKEN
- 43. Deploying to firebase ctnd ● Here is an example of how you can access it in your GitHub Actions script ● NEVER REVEAL THIS TOKEN PUBLICALLY (ex. Don’t hardcode the actual value of the token in your github actions script)
- 44. Deploying to firebase ctnd Let’s go over and explain what is happening in the deploy.yaml script found here (don’t worry, the finished script is already on your computer if you forked the workshop GitHub repository 😄)
- 46. GitHub Actions config ● If you got everything done up to this point, try making a change to the React code and pushing it to the repo (careful! Your changes might break the automated tests I set up 😄 Try just adding <h1>hello</h1> somewhere (that shouldn’t break anything :) ) ) ● If you click the “Actions” tab in the repository you should see the Action running!
- 47. A final note ● You can run workflows manually by clicking “run workflow as seen below
- 49. We have a React App Create a firebase project “Firebase-ify” our React project We can deploy it manually by typing in: firebase deploy We created a CI/CD pipeline using GitHub actions: (Writing a script that GitHub ran on its servers) THIS RAN ON EACH PUSH TO THE MAIN BRANCH IN OUR GITHUB REPOSITORY ● Installed dependencies for the react app, Built the react app, ran the tests ○ If any of the tests failed, the GitHub action would stop running and tell us that something went wrong ● Deploy the firebase app to the internet