DevOps CI/CD?

CI/CD stands for Continuous Integration and Continuous Deployment (or sometimes Continuous Delivery). It’s a set of practices and tools used to automate the process of building, testing, and deploying your code, making development faster and more reliable 

Continuous Integration (CI): This is about frequently merging your code changes into a shared repository (e.g., GitHub). Each time you push code, CI tools automatically:  

• Build your app (e.g., compile your Next.js code). 
• Run tests (e.g., check if your app has errors or bugs). 
• Ensure the code works before it’s merged. 
• Example: You write a new feature for your Next.js app and push it to GitHub. The CI tool checks if the code builds correctly and passes tests. 

 

Continuous Deployment (CD): This takes it further by automatically deploying your code to a server (e.g., Vercel, AWS) after it passes CI checks. 

•  Example: After your Next.js app passes the build and tests, it’s automatically       deployed to a live website for users to see. 
• In Simple Terms: CI/CD is like having a robot that checks your code for errors and puts it online automatically every time you make changes. It saves you from manually building, testing, or uploading your app. 

 

DevOps are the practices of build, test and release  code in small frequent steps. 

Creating workflow- Reference from Git hub  

 

What It Is 

A Continuous Integration (CI) pipeline is a series of automated steps that run every time you push code changes to a repository (e.g., GitHub). These steps check that your code is valid, builds correctly, and doesn’t break existing functionality. “Building” a CI pipeline means configuring these steps using a tool like GitHub Actions or Vercel. 

• In Simple Terms: It’s an automated checklist that ensures your Next.js code is good before merging or deploying. For example, it checks if your app builds (npm run build) and passes tests. 
• Focus: The CI part of CI/CD, ensuring code integration is smooth, especially for teams or frequent updates. 

Key Stages of a CI Pipeline 

1. Code Commit: You push code to a repository (e.g., GitHub).  
2. Example: You add a new Next.js page and push it. 
3. Build: The code is compiled into a working app (e.g., npm run build for Next.js). 
4. Test: Automated tests (e.g., Jest for unit tests) check for errors. 
5. Deploy (optional in CI): Sometimes included in CI pipelines for preview deployments. 
6. Monitor/Feedback: The pipeline reports success or failure (e.g., GitHub shows a green checkmark or red X). 

 

 

Workflows Get a high-level overview of GitHub Actions workflows, including triggers, syntax, and advanced features. 

In this article About workflows Workflow basics Workflow triggers Next steps About workflows A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule. 

Workflows are defined in the .github/workflows directory in a repository. A repository can have multiple workflows, each of which can perform a different set of tasks such as: 

Building and testing pull requests Deploying your application every time a release is created Adding a label whenever a new issue is opened Workflow basics A workflow must contain the following basic components: 

One or more events that will trigger the workflow. One or more jobs, each of which will execute on a runner machine and run a series of one or more steps. Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow. For more information on these basic components, see Understanding GitHub Actions. 

Diagram of an event triggering Runner 1 to run Job 1, which triggers Runner 2 to run Job 2. Each of the jobs is broken into multiple steps. 

Workflow triggers Workflow triggers are events that cause a workflow to run. These events can be: 

Events that occur in your workflow’s repository Events that occur outside of GitHub and trigger a repository_dispatch event on GitHub Scheduled times Manual For example, you can configure your workflow to run when a push is made to the default branch of your repository, when a release is created, or when an issue is opened. 

Workflow triggers are defined with the on key. For more information, see Workflow syntax for GitHub Actions. 

The following steps occur to trigger a workflow run: 

An event occurs on your repository. The event has an associated commit SHA and Git ref. GitHub searches the .github/workflows directory in the root of your repository for workflow files that are present in the associated commit SHA or Git ref of the event. A workflow run is triggered for any workflows that have on: values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run. Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, GitHub sets the GITHUB_SHA (commit SHA) and GITHUB_REF (Git ref) environment variables in the runner environment. For more information, see Store information in variables.