Nordic APIs’ Post

🚀 Day 21: Automating Deployments with Continuous Delivery (CD) Today I took the next big step in automating my development workflow by setting up Continuous Delivery (CD). With CI/CD in place, I now have an automated process that not only tests but also deploys my Node.js app whenever new code is merged into the main branch. Here’s how I made it happen: 1. Setting Up Continuous Delivery with GitHub Actions: After setting up Continuous Integration, I expanded the pipeline to include Continuous Delivery. Now, after every successful test, my app is automatically deployed to the server (in this case, Heroku). Here’s an overview of my updated GitHub Actions workflow: name: Node.js CI/CD on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up Node.js uses: actions/setup-node@v2 with: node-version: '14' - run: npm install - run: npm test deploy: runs-on: ubuntu-latest needs: build steps: - uses: actions/checkout@v2 - name: Deploy to Heroku env: HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }} - run: git push https://lnkd.in/gTqk9DGm main This pipeline now builds, tests, and automatically deploys my app to Heroku if all tests pass! 2. Deploying to Heroku: I chose Heroku for its simplicity and ease of integration with GitHub. It allows me to deploy my app with just a git push command, and it scales effortlessly as the project grows. Now, with CD in place, my app gets deployed automatically after every successful push to the main branch! 3. Why Continuous Delivery Matters: CD ensures that my application is always in a deployable state. It saves time and reduces the risk of human error in manual deployments. This setup is crucial for faster development cycles, especially in production environments. 4. Next Steps: I’m going to further enhance my pipeline by adding environment-specific configurations for staging and production, ensuring that I can push changes safely to different environments. Up Next: Tomorrow, I’ll dive deeper into managing environment variables and secure deployment configurations! #Nodejs #ContinuousDelivery #GitHubActions #Heroku #CD #BackendDevelopment

📢 Just in ! Microsoft announced full #Git Integration with #PowerPlatform 💡 Now in #PublicPreview, Git Integration provides a streamlined experience for developers and citizen developers to build solutions together using the same development processes and best practices. This is a native integration, you can source-control your solutions from the Make portal. Just to name few benefits, it will provide faster setup and iterations, developer and feature isolation, change tracking and auditing, version control, rollback, and more. 🔗 Read more: https://lnkd.in/drHDk8xj

Do you use CI/CD in your SW development process? A proper workflow could easily automate your releasing/testing process during development. You can easily deploy, execute, test your application on a self-hosted server. Github built-in, straight forward CI/CD pipeline helps you in that! #software #softwareengineering #cicd https://lnkd.in/gFXGSTH3

🛠️ Did you know? 🛠️ You can automate your deployments using GitHub Actions on shared hosting like HostGator. Effortlessly streamline your workflow, automate tasks, and keep your site up-to-date with the latest features and fixes. Ready to transform your deployment process? Check out our detailed guide and unlock the potential of GitHub Actions today! 🚀✨ #GitHubActions #DevOps #CI #CD #Automation #WebDevelopment #HostGator #TechTips https://lnkd.in/gmKdcuUm

Thinking of Versioning your APIs? Here is a good starting point on getting your head around what strategy could work.

I stumbled over a paper of uber and their SubmitQueue approach to "Keeping Master Green at Scale" about Continuous integration and delivery in monolithic / monorepo applications, and how this really can become tricky on scale - as I know first-hand. The benefit of all engineers being able to change things fast everywhere, moves more complexity to 1) test automation 2) integration. Beyond the most important issue of a working testing strategy, which means fast, exactly enough coverage, not-flaky - the integration of changes into main becomes very relevant. You must not be blocked for an urgent release by a broken main and 10s and 100s of change set ahead of you. Github and gitlab offer similar solutions. * Keeping Master Green art scale, 2019: https://lnkd.in/dPFviE34 * Bypassing Large Diffs in SubmitQueue, Uber, 2023: https://lnkd.in/d2c3qAus * Github merge queue: https://lnkd.in/diqpca6j * Gitlab mergetrain: https://lnkd.in/d_s28ktV

My story of using Retool to automate deployment notifications from GitHub and Heroku via Telegram Messenger. Low-code platform is truly useful and easy-to-use to perform such operational, repetitive tasks. https://lnkd.in/gjiDpvt6

🚀 **Excited to announce my latest full-stack project: DevStream!** 🚀 I’m thrilled to introduce **DevStream**, a real-time code collaboration platform designed to allow multiple users to collaboratively write, edit, and compile code with real-time synchronization. This project was an exciting challenge, and I’ve leveraged several powerful technologies to create a seamless experience for developers. 🔧 **Key Features & Tech Stack:** ✨ **Real-time Code Collaboration**: Built with **React.js** on the frontend and **Node.js** with **Express.js** on the backend, DevStream enables users to collaboratively write and edit code with real-time updates. We’ve integrated **WebSocket** for real-time communication, ensuring changes are instantly synchronized across all users. ⚡ **Seamless Code Execution**: DevStream integrates the **JDoodle API** to support seamless code execution and compilation across multiple programming languages. Users can instantly run their code within the same platform and get real-time output during collaborative coding sessions. 📡 **Robust Communication & Messaging**: To ensure efficient and reliable real-time updates, we used **WebSocket** for communication between users and **RabbitMQ** for message queuing and synchronization. This ensures that data transmission is both fast and reliable, even under heavy load. 💾 **Backend & Database**: The backend is powered by **Node.js** and **Express.js**, with **MongoDB** for storing user sessions and collaborative data. 🐳 **Dockerized Environment**: To ensure a smooth development process and deployment, the entire platform is containerized using **Docker**, making it easy to scale and manage the system across different environments. 🚀 **Real-Time Scalability**: The combination of **RabbitMQ** and **WebSocket**, along with the performance of **MongoDB** and **Docker**, allows DevStream to handle multiple users in real-time, ensuring a highly responsive and efficient coding experience. Use This -> https://lnkd.in/geMvbxdn server -> https://lnkd.in/g3qGEata client -> https://lnkd.in/gHqPshKQ Docker Image - docker pull pruthiraj/devstream   docker run -d -p 4005:4005 pruthiraj/devstream This project has been a great journey in building real-time applications with efficient backend architectures. If you're working on or interested in real-time collaboration tools or similar projects, I’d love to connect and hear your thoughts! #FullStackDevelopment #RealTimeCollaboration #WebDevelopment #ReactJS #NodeJS #ExpressJS #MongoDB #WebSocket #RabbitMQ #JDoodleAPI #Docker #DevStream #CollaborativeCoding #TechInnovation

If you code and consider going on-premise (i.e. no SaaS for whatever reason) then Github is one of the key obstacles, with all the bells and whistles. After trying GitLab, Gogs and Gitea i've discovered that https://OneDev.io is a great source code + package server + issue tracker. Installs in minutes, super fast and is so much faster to configure than GitLab (sorry!). Now if only it supported Mercurial... (or maybe even Fossil, huh?)