Slide 1 ----------- Part 1: Let's discuss how you can make your development cycle safer and more transparent towards your testing team. CI/CD is where the magic happens! Slide 2 ----------- Part 1: Picture this: In our cool blogging app, your colleague adds a “sort by date” feature—awesome, right? But then the app crashes because no one tested it properly. CI/CD is like a superhero that catches these mistakes before they ruin everything! Slide 3 ----------- Part 1: Remember Crowdstrike mess in 2024, when a software error made airports and even hospitals shut down? A good executed CI/CD would prevent this mess. Slide 4 ----------- Part 1: CI/CD stands for Continuous Integration and Continuous Deployment. It’s all about automating the boring stuff—testing and launching your app—so you can focus on creating cool features. Big apps like TikTok or Medium use it to stay bug-free, and you can too! Part 2: Ever shared a project with a friend, and it didn’t work on their computer? CI/CD ensures your code works everywhere, every time—no more excuses! Part 3: Some think, “I can test it myself—it’s faster!” But manual testing gets messy as your app grows. Another myth: “CI/CD is too hard for beginners.” Nope—it’s easier than you think, and we’ll prove it today! Slide 5 ----------- Part 1: Continuous Integration, or CI, is like a team huddle. Everyone brings their code—like a new filter for blog posts—and CI checks it works with the main app. It runs tests automatically to spot problems fast. Part 2: Continuous Deployment, or CD, takes your tested code and puts it live—like publishing your blog app for the world to see—without you lifting a finger. Continuous Delivery is similar but waits for your “go.” Both save time! Part 3: Why does it matter? You get feedback quickly! Did it break? Is it working as expected? Fewer bugs sneak in, and teamwork feels smooth. No more “it works on my machine” headaches! Also, it builds confidence! In our blog app, users see posts and filter by tags; admins add posts. CI/CD tests the filters and deploys new code seamlessly. Part 4: CI/CD also strengthens security in your app and implements crucial principles. We can picture it like a guard tower protecting our app. Part 5: Secure design principle builds security into our app from day one—like ensuring our admin login page isn’t easily hackable. You ensure that security-related tests are in your code base. If we skip this, the whole tower falls! Part 6: Next, we protect the app data. This means keeping secrets safe—like not exposing our admin password in the code. For our app, we’d hide API keys in environment variables so hackers can’t steal user data. Part 7: Then we have Operational Continuity. This ensures our CI/CD pipeline runs smoothly—like deploying new blog posts without downtime. If our pipeline breaks, users can’t see the latest content! Part 8: At the top is Trust Maintenance. It’s about keeping our pipeline trustworthy—like ensuring no one sneaks bad code into our app. For us, this means only trusted team members can approve deployments. Part 9: This hierarchy keeps our blog app safe at every step. Secure Design protects the admin panel, Data Protection hides user info, Operational Continuity keeps posts live, and Trust Maintenance ensures our CI/CD pipeline isn’t tampered with. Security is a team effort! Slide 6 ----------- Part 1: Here’s the CI/CD Infinity Loop—that shows the full lifecycle of your app. Part 2: The right loop is where the action starts. It’s a clockwise cycle: Plan is brainstorming—like deciding to add a ‘filter by tag’ feature. Code is writing it in TypeScript. Build is compiling it into something runnable, like bundling our Next.js app. Test is running automated checks—does the filter work? If not, we will fix it here before crossing over. Part 3: The left loop picks up after tests pass. It’s also clockwise: Release packages the app—like zipping it into a deployable file. Deploy sends it live to a server for users. Operate is the app running—users filtering posts. Monitor watches for crashes or slow performance, feeding info back to Plan via a dotted line, closing the loop! Part 4: For our app, we plan a tag filter, code it, build the NextJS app, and test it (CI). Once it’s solid, we release a package, deploy it to Vercel, operate the live site, and monitor user feedback (CD). The crossover ensures only good code goes live! Slide 7 ----------- Part 1: Let’s use GitHub Actions to set up Continuous Integration for our Next.js blogging app. It’s a robot that runs our tests and builds every time we push code—keeping our app reliable. We’ll break down each part of this workflow file! Part 2: The workflow file is a YAML file that must be stored in the dot github/workflows directory. In our case, we named it ci yml. YAML is a more concise version of XML. Part 3: We name this workflow CI Pipeline. You can have several pipelines in the same codebase and choosing a good name is beneficial. Our name ... sucks. Part 4: Then we need to define triggers, which specify when do we want to run our pipeline. You can run simple pipelines on every push, but deployment pipelines only when code is pushed to the main brach. In this case, push runs this when we update the main branch—like adding a new feature. The "pull_request" also runs it when we propose changes—keeping teamwork safe! Part 5: Then, we can define several jobs; in our case, we define a new job we named build-and-test. Think of jobs as chapters in the robot’s to-do list—one job can have many steps! Part 6: Next, we need to provide the container in which this pipeline runs. If you are not aware of containers, they are like virtual machines that you can run on your computer, with different operation systems. In this case, we chose the Linux system, Ubuntu, from the container ubuntu-latest—it becomes the computer the robot uses, a Linux machine provided by GitHub, fresh and fast! Part 7: Steps provide the step-by-step instructions. Each step is a mini-task—like fetching code or running tests—that builds up to a solid app! Part 8: The "uses" property provides the name of the action you wish to execute. In our case, actions/checkout step uses a pre-made action to fetch our blog app’s code from GitHub. It’s like downloading the latest version so the robot can start working! Part 9: You can also name your action, in this case we named it Setup NodeJS. We use actions/setup=node action to set up Node.js , which Next.js needs to run. The ‘with’ part customises it—think of it as telling the robot, “Use this tool kit!”. In our case, we tell the robot to use NodeJS version 18! Part 10: Next, we install our favourite package manager PNPM, and we specify to use version 10 4 1. Part 11: We can also run command in the target operating system, provided in the run parameter. This command installs all libraries that our blog app depends on. You do it locally, we need to do it in the container! Part 12: Then, we run another command to execute our tests. Part 13: If all steps are executed well, we will build our project. There could be some build or compilation errors. It's always good to build the app to ensure the CD pipeline does not crash! Pretty impressive, huh? It's like providing a robot with a recipe of things you would like to create! Slide 8 ----------- Part 1: Imagine our blog app is live. Users love filtering posts by “travel” or “tech,” and admins add posts daily. But one day, an admin adds a buggy “delete post” feature—yikes! Part 2: Manually testing means the bug slips through. Users click “delete,” and all posts vanish. Panic ensues, and we scramble to fix it after complaints roll in. Part 3: GitHub Actions catches the bug in testing. The pipeline fails, alerting us before deployment. We fix it, re-run the pipeline, and deploy a safe update. Users never notice a thing! Part 4: CI/CD saves time, stress, and our app’s reputation. Automation beats chaos every time! Slide 9 ----------- Part 1: Let’s get you coding! You’re going to clone a real repo, make a change, and see GitHub Actions in action—catching bugs like a pro! Part 2: Fork and grab this pre-made Next.js app repo from GitHub. Part 3: Try something simple—like changing the blog title in pages/index.tsx from “My Awesome Blog” to “My Broken Blog.” Or add a bug, like deleting a semicolon, to break the test! Part 4: Commit your change and push it to your forked repo with git push. This triggers the CI pipeline we set up! Part 5: Head to the “Actions” tab in your GitHub repo. You’ll see the CI Pipeline running—testing and building. If you added a bug, it’ll fail and tell you why. Fix it, push again, and see it pass. Instant feedback! Slide 10 ----------- Part 1: I’ve tinkered with GitHub Actions a ton. Pushing tiny changes to test them online can take forever—commit, push, wait, repeat. Good news: there’s a tool called ACT to run GitHub Actions locally, so you can experiment faster! Part 2: To run Github Actions locally you must install Docker Desktop—it’s like a mini virtual machine that runs the same environment GitHub Actions uses. Download it from docker.com and set it up! Part 3: Then, you need the ACT tool. Please use instructions on their website to install it on your computer. On mac its as simple as running brew install act. Part 4: Then we need to do one adjustment. In Docker Desktop, go to Settings General Virtual Machine Options. Switch the file-sharing implementation to gRPC FUSE. I had to do this to make ACT work smoothly—saves you the headache! Part 5: To run this, run act with j parameter build-and-test in your cloned repo folder or just run "act" to execute all pipelines. This simulates the “build-and-test” job from our CI pipeline locally. You’ll see it fetch code, install NodeJS, run tests—everything, right on your screen! Act tool allows you to tweak the pipeline—like adding linting—without spamming GitHub. It’s faster, and you’ll feel like a CI wizard! Slide 11 ----------- Part 1: You have many other options when it comes to creating CI pipelines. Let's explore a few! Part 2: Jenkins is a popular CI tool that’s been around forever. It’s an open-source platform you install on your own server. For our blog app, Jenkins can run tests and builds just like GitHub Actions, but you’d set up a ‘pipeline’ in a Jenkinsfile—similar to our ci yml. It’s super customisable, so you can add plugins for everything, like Slack notifications when a build fails! Part 3: CircleCI is cloud-based, like GitHub Actions. It’s great for speed—think of it as a racecar for testing our blog app’s tag filters. It uses a config yml file and has a cool dashboard to watch builds. Part 4: Travis CI is another cloud option, often used for open-source projects. It’s simple to set up with a travis yml file, perfect for beginners testing our admin post feature. Part 5: GitLab CI/CD is built into GitLab, a GitHub alternative. It uses a gitlab-ci yml file and can deploy our blog app to a server—great if you’re already using GitLab! Part 6: If we compare how easy is to use Github Actions with alternatives, GitHub Actions wins here—it’s built right into GitHub, so you don’t need a separate setup. Jenkins requires installing on a server, which can be tricky for beginners working on our blog app. Part 7: GitHub Actions takes the prize for cost as it is free for public repos and has a generous free tier for private ones—perfect for students. Jenkins is free but needs a server (which might cost money). CircleCI and Travis CI have free tiers but charge for more usage. Part 8: Jenkins is the king of customization—you can make it do anything with plugins. GitHub Actions is flexible too, with reusable ‘actions,’ but Jenkins has more options for complex setups, like integrating with older systems. Part 9: GitHub Actions has a huge community because it’s part of GitHub—tons of pre-made actions for our blog app. Jenkins has a big community too, but it’s older, so some resources feel dated. Slide 12 ----------- Part 1: CI/CD saves the day. It keeps our blog app safe by testing every change and deploying smoothly. CI checks the code; CD gets it live. Part 2: GitHub Actions rocks. Our robot helper automates testing and building—like a guardian for our app’s quality. Part 3: Automate early, test everything, and use GitHub to stay organised. It’s how pros ship great apps! Part 4: Don’t skip tests thinking “it’s fine”—one typo could crash your app later. Trust CI/CD instead!