How to Set Up CI/CD with GitHub Actions for Personal Projects

🚀 Setting Up CI/CD in GitHub Actions for Personal Projects In the world of software development, automating the continuous integration and deployment process is key to efficiency and quality. Recently, I explored how to implement a robust CI/CD pipeline using GitHub Actions in my personal project, transforming manual workflows into automated and reliable processes. This approach not only accelerates development but also minimizes human errors, ensuring consistent testing and rapid deployments. 🔧 Initial Environment Setup Before diving into the code, it's essential to properly configure the repository to make the most of GitHub Actions' capabilities. ✅ Create the workflow file: Start with a YAML file in the .github/workflows folder, defining the workflow name and the events that trigger it, such as pushes or pull requests. ✅ Configure the runner: Select the operating system (e.g., ubuntu-latest) and the version of Node.js or the relevant language for your tech stack. ✅ Handle secrets: Store sensitive credentials like API tokens in the repository settings to maintain security. ⚙️ Pipeline Structure: Jobs and Steps The heart of CI/CD lies in defining jobs that execute sequential or parallel tasks, ensuring each step validates the code before proceeding. 🔍 Unit Tests: Implement a job that runs tests with tools like Jest or Mocha, failing the build if there are errors to prevent defective merges. 📦 Build and Packaging: Next step, compile the project and generate artifacts, optimizing for production environments with minification and bundling. 🚀 Automatic Deployment: Use actions like deploy-to-vercel or aws-actions to push changes to servers, conditioned by specific branches like main. 🛡️ Best Practices and Optimizations To elevate your pipeline, incorporate strategies that make it scalable and maintainable. ⚡ Dependency Caching: Speed up builds by reusing node_modules or downloaded packages, drastically reducing execution times. 📊 Monitoring and Notifications: Integrate Slack or email notifications for failure alerts, and use badges in the README to display the workflow status. 🔒 Security at Every Step: Validate dependencies with tools like Dependabot and automatically scan for vulnerabilities. Implementing CI/CD in GitHub Actions has revolutionized my workflow, enabling faster iterations and cleaner code. If you're in backend or frontend development, this free tool is a game-changer. For more information, visit: https://enigmasecurity.cl #CICD #GitHubActions #DevOps #Automation #SoftwareDevelopment #TechTips If you like this content and want to support more technical news, consider donating to the Enigma Security community: https://lnkd.in/er_qUAQh Connect with me on LinkedIn to discuss more about cybersecurity and DevOps: https://lnkd.in/eMjz8bpJ 📅 Sun, 19 Oct 2025 11:09:53 GMT 🔗Subscribe to the Membership: https://lnkd.in/eh_rNRyt

⭐ 𝐈𝐧𝐭𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐭𝐨 𝐆𝐢𝐭 𝐚𝐧𝐝 𝐆𝐢𝐭𝐇𝐮𝐛 — 𝐓𝐡𝐞 𝐒𝐭𝐚𝐧𝐝𝐚𝐫𝐝 𝐓𝐨𝐨𝐥𝐬 𝐟𝐨𝐫 𝐌𝐨𝐝𝐞𝐫𝐧 𝐃𝐞𝐯𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬 ⭐ If you are building software in 2025, Git and GitHub are essential. After more than 30 years working across enterprise systems, cloud projects, and AI development, I can say that mastering Git is one of the most powerful steps any IT professional can take. Git keeps your work structured, traceable, and safe. GitHub brings global collaboration, automation, and integration into the picture. 🔧 𝐖𝐡𝐚𝐭 𝐈𝐬 𝐆𝐢𝐭? Git is a distributed version control system that tracks every change in your code. It allows you to: Save snapshots of your work Experiment in isolated branches Collaborate across teams Reverse mistakes instantly While working on AI agent frameworks, cloud infrastructure, and backend services, Git has always been the backbone of controlled development. 🌐 𝐖𝐡𝐚𝐭 𝐈𝐬 𝐆𝐢𝐭𝐇𝐮𝐛? GitHub is a cloud platform built on top of Git that gives developers a shared workspace. It provides: Remote repositories Issue and project tracking Pull requests for safe collaboration Documentation via README and wikis CI/CD with GitHub Actions Integrations with AWS, Azure, Google Cloud, and countless tools In many of the client projects I have worked on—AI, MLOps, cloud-native apps—GitHub has been the central place where development happens. 🚀 𝐖𝐡𝐲 𝐆𝐢𝐭 𝐚𝐧𝐝 𝐆𝐢𝐭𝐇𝐮𝐛 𝐌𝐚𝐭𝐭𝐞𝐫 While working across multiple industries, I have seen Git and GitHub help teams achieve: Consistent workflows across developers Full transparency of changes Automated testing and secure deployments Faster onboarding for new engineers They are the tools that allow people to work quickly and confidently in complex environments. 🏁 𝐇𝐨𝐰 𝐓𝐨 𝐆𝐞𝐭 𝐒𝐭𝐚𝐫𝐭𝐞𝐝 1️⃣ Install Git 2️⃣ Create a GitHub account 3️⃣ Initialize your first repository 4️⃣ Commit and push your code 5️⃣ Practice branching, merging, and pull requests You can start with something simple—Python scripts, cloud templates, AI prompt libraries. The more you use Git, the more natural it becomes. 👍 Like 💬 Comment 🔁 Share 🔄 Repost Check out the pdf attached for more insights. Also, follow me, Leonardo Santos-Macias. PhD, MSc for more like this. #AWS #Azure #GoogleCloud #CloudCertifications #CloudCertificationStore #Git #GitHub #DeveloperTools #VersionControl #SoftwareEngineering #Programming #Python #Java #CSharp #DevOps #CloudEngineering #MLOps #AIEngineering #OpenSource #FullStack #BackendDevelopment #TechSkills #DigitalSkills #LearningPath #DeveloperJourney #FutureOfWork

𝗚𝗶𝘁 𝗰𝗵𝗮𝗻𝗴𝗲𝗱 𝘁𝗵𝗲 𝗴𝗮𝗺𝗲! 96% of developers use Git. Let’s talk about how Git went from just another tool -> to the tool that every developer relies on today. Git was born in 2005, created by none other than Linus Torvalds, the same legend behind the Linux kernel. Story goes: The Linux team lost access to their old version control system. So Linus said, “Fine, I’ll build one.” And just like that, Git was born. He built it for Linux kernel developers, people working on one of the most complex, fast-moving codebases in the world. That meant it had to be fast, distributed, and built for chaos. From day one, Git could handle repositories with tens of millions of lines of code. Speed and performance weren’t afterthoughts, they were core design goals. 𝗦𝗼, 𝘄𝗵𝗮𝘁 𝗶𝘀 𝗚𝗶𝘁 𝗿𝗲𝗮𝗹𝗹𝘆? Git is an open-source, distributed version control system that manages versions of code (and even data). But here’s the thing, Git doesn’t just track files line by line like a simple document tracker. It’s way smarter than that. Git tracks snapshots.  Every time you commit, Git takes a snapshot of your entire project’s state, efficiently storing only what’s changed. Under the hood, it’s powered by a key-value store using SHA-1 hashes. Every commit points to a full snapshot of your repo, not just the changes. Those long hashes you see? They uniquely represent your content, no two different files share the same one. Everything in Git is stored as an object: - Blobs for file contents - Trees for directories - Commits for snapshots of your files and meta data And here’s the wild part Git is content-addressed, not file-name-based. That means Git doesn’t care what the file is called, only what’s inside. If the content changes -> the hash changes. If the content’s the same -> Git reuses it. That’s why Git is insanely efficient, even when versioning huge config repos like Terraform, Kubernetes manifests, or Helm charts. Today, if you’re doing anything in DevOps, cloud, or code, Git is probably at the center of it. So yeah, Git didn’t just change the game. The smart, compressed, hash-based snapshot engine became the game! #DevOps #Automation #Git #Linux #Scripting #CloudEngineering #Infrastructure #CoderCo

Day 29 of #100DaysOfDevOps — Managing Git Workflow with Pull Requests One of the most important DevOps principles is collaboration with control — ensuring code quality through peer review before merging into production-ready branches like main or master. Today’s focus was on Git Pull Requests (PRs) — the standard workflow for proposing, reviewing, and approving code changes in a controlled environment like GitHub or Gitea. Concept Recap A Pull Request allows contributors to: 1. Propose changes from one branch to another (e.g., from story/fox-and-grapes → master) 2. Request review from teammates 3. Ensure only approved and tested changes make it to production Steps 1. Created a feature branch story/fox-and-grapes and committed Max’s story there. 2. Opened a Pull Request (PR) in the Gitea UI with title “Added fox-and-grapes story”, pulling from the feature branch into master. 3. Assigned Tom as a reviewer to ensure code validation and peer review. 4. Logged in as Tom, reviewed the PR, and merged it into the master branch once approved. Importance of PRs: Pull Requests help maintain code integrity, enable peer collaboration, and protect production branches from accidental or unreviewed changes — a key DevOps best practice for CI/CD pipelines. Tip: Automate PR checks using CI tools (like GitHub Actions or Jenkins) to enforce tests before merges. Learn more: https://lnkd.in/deuV3DSG #Git #DevOps #VersionControl #Collaboration #KodeKloud #100DaysOfDevOps

🔧 Everyone's using basic Git workflows, but triangular workflows in GitHub CLI are a game-changer most devs are sleeping on Here's what you're missing: 1. GitHub CLI Triangular Workflows (v2.71.2) → Pull from main, push to your branch automatically → 0 manual rebasing needed → Free: Yes ✅ 2. Alternative Setups That Are 10x Smoother: ▸ Branch-Level Triangle → Set different merge/push paths per branch → Perfect for feature branch workflows → No more git rebase headaches ▸ Fork-Level Triangle → Automatic upstream syncing → Push to fork, pull from source → Ideal for open source contributors 💡 Pro Tip: Use 'pushremote' in .git/config to set this up in 30 seconds: [branch "yourbranch"] remote = upstream pushremote = origin 🔥 Why this matters: • 4.5 years in development • Eliminates manual branch syncing • Works seamlessly with gh pr commands Save this before it becomes mainstream! 📌 Which setup are you implementing first - branch or fork-level? 📖 Read full article: https://lnkd.in/euUtBmER #GitHub #GitHubCLI #DevTools #Programming #Git #DevOps #OpenSource #CodingTips

Today I successfully set up Jenkins on my server and built a simple CI/CD pipeline that connects GitHub → Jenkins → Docker Hub 💡 Here’s what I learned and did step by step 👇 1️⃣Set up Jenkins with Docker I started by running Jenkins inside a Docker container: sudo docker run -d --name jenkins \ -p 8080:8080 -p 50000:50000 \ -v jenkins_home:/var/jenkins_home \ jenkins/jenkins:lts Then I unlocked Jenkins, installed the suggested plugins, and created my admin user. Jenkins is now available at http://your-server-ip:8080 🎉 2️⃣ Connected Jenkins to GitHub I linked Jenkins with my GitHub repository by adding: A GitHub webhook to trigger builds automatically My repository URL inside a Jenkins pipeline job So every time I push code → Jenkins automatically detects changes 🚀 🐳 3️⃣ Built and Pushed Docker Image to Docker Hub Next, I added my Docker Hub credentials in Jenkins (Manage Jenkins → Credentials) and created a pipeline like this: pipeline { agent any stages { stage('Clone Repo') { steps { git 'https://lnkd.in/eiFVbgf2' } } stage('Build Docker Image') { steps { sh 'docker build -t your-dockerhub-username/your-app:latest .' } } stage('Push to Docker Hub') { steps { withCredentials([usernamePassword(credentialsId: 'dockerhub', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS')]) { sh 'echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin' sh 'docker push your-dockerhub-username/your-app:latest' } } } } } ✅ Jenkins automatically builds the Docker image and pushes it to Docker Hub whenever I push new code to GitHub. 4️⃣ Result This simple project gave me a full CI/CD workflow: GitHub → Jenkins → Docker Hub Code push = automatic build + deploy It helped me understand how DevOps automation really connects everything together Next Goal Next, I’ll connect Jenkins with Ansible to automate deployment to servers. 🏷️ #DevOps #Jenkins #Docker #GitHub #Automation #CI/CD #LearningJourney

⚙️ Git Workflow 1️⃣ Initialize Git git init Creates a hidden .git folder to track changes. Check it using: ls -la 2️⃣ Check Repo Status git status Shows if files are tracked, untracked, or committed. 3️⃣ Add Files git add filename Adds files to the staging area for tracking. Add all files: git add . 4️⃣ Commit Changes git commit -m "Added new feature" Saves a checkpoint with your message. 5️⃣ View Changes git diff # Show modifications git log # Show commit history 6️⃣ Undo or Go Back git reset --hard <commit-id> Goes back to a specific commit version. 🚀 Push Code to GitHub Steps: Create a GitHub account. Create a new repository. Connect local repo to GitHub: git remote add origin <repo_URL> Push your code: git push -u origin main 🔄 Pull and Fetch git pull Fetch and merge latest changes from remote git fetch Fetch updates but don’t merge automatically Use pull to get updates + merge. Use fetch when you just want to see new updates before merging. ⚙️ .gitignore File .gitignore tells Git which files to ignore while tracking. 🌿 Git Branching Strategy Why Use Branches? To work on new features or bug fixes without breaking main code. Makes teamwork smoother and organized. Common Branch Types Main / Master Branch: Always stable and production-ready. Feature Branch: Used to develop new features. Release Branch: Used for preparing code for deployment. Hotfix Branch: Used for urgent fixes in production. 🔄 Branch Commands git branch # List all branches git checkout -b feature1 # Create and switch to new branch git checkout main # Switch back to main branch git merge feature1 # Merge feature branch into main 🔁 Merge, Rebase, and Cherry-Pick 🔸 Merge Combines code from one branch into another. Keeps all commit history. 🔸 Rebase Rewrites commits in a straight line (clean history). Commonly used in professional DevOps workflows. 🔸 Cherry-Pick Pick a specific commit from one branch to another: git cherry-pick <commit-id> 👥 Pull Requests (PR) Used on GitHub when one branch wants to merge into another. Allows code review and approval before merging. Ensures quality and teamwork. 🧩 Example Git Workflow in Real Projects Developer creates a feature branch → works on code. Runs tests and commits changes. Pushes the branch to GitHub. Opens a Pull Request (PR) for review. Once approved → merged into main branch → deployed. Done😎 😎 #GitGithub #Devops

🔧 Everyone's using basic Git workflows, but triangular workflows in GitHub CLI are a game-changer most devs are sleeping on Here's why it matters: Standard workflow: → Branch → Change → Push to same branch → Requires constant merging/rebasing 😫 New Triangular workflow (gh CLI v2.71.2): → Pull from main directly to feature branch → Push to your own branch → Zero manual syncing needed 🚀 3 ways to set it up: 1. Branch Config → Simple .git/config modification → Perfect for single repo work 2. Push Remote → Ideal for fork-based development → Separate push/pull destinations 3. Push Default → Repository-wide settings → Best for consistent team workflows Pro tip: Use @{push} syntax to instantly see your push destinations 🎯 Why this is massive: • 4.5 years in development • Works seamlessly with GitHub PRs • Zero extra commands needed • Matches Git's native behavior 💡 Save this if you're tired of constant branch syncing! What's your current Git workflow looking like? Let me know below 👇 📖 Read full article: https://lnkd.in/euUtBmER #GitHub #GitHubCLI #DevTools #Programming #Git #DeveloperProductivity #Tech #OpenSource

New workflows for #SCM, or how to simplify DevX for tiny teams, and projects where the ratio of gitninja < gitphobic is skewed heavily towards people who really will never ever learn git. Call it skills deficiency, call it getting away with thumb drives and using web interfaces to upload files into github, it is akin to not learning to read as a developer. Not making a value judgement, but I have discovered a lot of devs over the years who have figured out how to not ever learn git, and secretly (or openly) refuse avoid using source control. There are a number of techniques I've seen to avoid using a git workflow: - use a thumb drive and hand the code to a coworker who will do the merge - start a merge or commit or push (usually some combo of this ... the commands were written down but never really understood so this gets dangerous fast) and call me (or someone) over to help when stuck - don't push code. Tell the boss bleep you. Excuse yourself for the day as you aren't in a good mood. I've seen this. - use unprotected main, and push using destructive techniques (seen this) - email the code to people (dangerous as you don't always get the right person in "outlook") - maintain a huge gigantic history at the header of the code, usually all in one file (never mind, git and any SCM will graciously maintain history) - uses a cheatsheet or notebook of commands, or an LLM to figure out what to do (see my last post) - never branch The list goes on. What is the answer to this? I agree the number of things you need to know as a person who works with an engineering team just to use git effectively is large, and vast. Brilliant people struggle with hit. So I will write this down: - In some cases you don't need git. But you need history. You need security of not losing work. Let this person use the SCM (Subversion/CVS) they remember. A good RE/DevOps person can mirror the repo to git. - Use a gatekeeper: In most companies now, there is a gatekeeper now. You can't simply push code. So quit torturing this person, but set up rules for how often and how code gets delivered - Or: I'm going to try out new SCMs that have the good features of git (namely distributed, low cost branching/forking) and leave out the features that most people don't need. The goal is not to create an elite force of people who all have the same skills. You need the designer. You need the EE. You need that i18n specialist. You need that marketing person (nah ... just kidding). So one goal for this coming year is to get familiar with other SCMs so I can quickly train up team members who are gitphobics and in situations where we can get by with a more simplified model of dev, something like Fossil SCM will work just great. You add files. You commit, and and wait, it already sync'd? No extra stuff. Nope. (credit: AI slop by Bing Image Creator using a prompt from human brain to make the perfect image DALL-3 or something. Writing by human intelligence slop).

🧠 Protecting Your Main/Master Branch — The Unsung Hero of a Healthy Git Workflow 🚀 Imagine pushing untested code directly to production. Or worse — accidentally deleting your main branch. 😱 That’s why branch protection is one of the most crucial (but often ignored) DevOps practices for maintaining code quality and team safety. 🔍 What Is Branch Protection? Branch protection is a set of rules and restrictions applied to critical branches like main or master in Git repositories (GitHub, GitLab, Bitbucket, etc.). 🏗️ Why It’s Important Without protection, anyone can: Force push changes and overwrite others’ commits Merge without reviews or testing Delete the main branch accidentally These lead to: ❌ Broken builds ❌ Lost commits ❌ Security risks ❌ Time wasted on rollback or debugging ⚙️ How to Protect Your Main/Master Branch (GitHub Example) You can enable this in GitHub → Settings → Branches → Add Rule ✅ Recommended settings: Require pull request reviews before merging Require status checks to pass (build/test must succeed) Require linear history (no messy merges) Disallow force pushes Disallow deletions Optional (but smart): Enforce signed commits Restrict who can push directly Require approvals from code owners 🧩 Example: Production-Safe Git Workflow main # Protected – production-ready code develop # Active dev branch for features feature/* # Feature-specific branches hotfix/* # Urgent bug fixes Flow: 1️⃣ Developer creates a feature branch 2️⃣ Pushes code and raises a PR 3️⃣ Code review + CI pipeline runs 4️⃣ Merge only after approval and tests pass 5️⃣ Main stays clean, tested, and deployable 🧠 Best Practices ✅ Protect main and develop branches ✅ Always merge via Pull Requests (never direct commits) ✅ Require at least one reviewer approval ✅ Run automated tests (CI) before merging ✅ Use branch naming conventions (feature/login, fix/api-timeout) ✅ Review branch protection rules regularly 💡 Pro Tips 💥 Add “CODEOWNERS” file for automatic reviewer assignment 💥 Combine protection rules with GitHub Actions or Jenkins pipelines 💥 Automate security scans before merging 💥 Use status checks to block PRs with failing tests 💥 Communicate branch policies clearly in README 🧠 Real-World Tip In production environments, large teams (like Netflix, Microsoft, or Amazon) treat main as “sacred code.” Every single change goes through: Peer review Automated build validation Security scan That’s how they prevent downtime or data breaches from small mistakes. “Protecting your main branch isn’t about blocking developers — it’s about protecting production and empowering quality delivery.” 🔐 🧠 Read more: https://lnkd.in/gSgb_jga #Git #GitHub #DevOps #CI/CD #BestPractices #SoftwareDevelopment #CodeReview #GitTips #EngineeringExcellence