When multiple developers are working on a project, the number of changes increases, and with it, the risk of errors. Without automated testing and delivery of changes, bugs can slip into production before they are noticed. CI/CD helps avoid this by enabling an automated process for testing, building, and deploying the project. Let’s take a look at how to set up CI/CD from scratch using GitHub Actions.
GitHub Actions is a built-in GitHub tool that allows you to run automatic actions on every commit, pull request, or push. Tests, builds, deployments, and notifications can be configured in a single YAML file. Everything works directly in the repository, without additional software. To get started, create a repository on GitHub if you don’t already have one. In the root of the project, create a .github/workflows folder and add a YAML file to it, for example ci.yml. It describes the events that will trigger the pipeline, as well as the sequence of tasks. Actions are activated automatically after committing the configuration file, no additional settings are required. GitHub automatically provides the $GITHUB_TOKEN token, which is used for API requests, pushes, and authorization in actions.
Let’s imagine a basic scenario: every time a push is made to the main branch, the project must be built, tested, and deployed to the server. In a YAML file, it looks like this: first, the code is cloned, dependencies are installed via npm, tests are run, and the project is built. All steps are performed in an isolated GitHub Actions environment based on Ubuntu. After these tasks are successfully completed, deployment begins, during which the code is downloaded again and the appleboy/ssh-action is used to connect to the server and transfer files. To avoid storing keys and passwords in the code, GitHub secrets are used, which are added in the Settings → Secrets and variables → Actions section and connected via ${{ secrets.NAME }}.
SSH and rsync are usually used for auto-deployment to the server. An SSH key is generated using ssh-keygen, the public part is added to the server, and the private part is added to GitHub Secrets. Next, the action connects to the server and executes the necessary commands, such as updating the code, installing dependencies, and restarting the service via PM2. If the application runs in Docker, it can be built into an image and sent to Docker Hub or GitHub Container Registry, and then the container can be updated on the server. For FTP deployment, SamKirkland/FTP-Deploy-Action is used, which synchronizes the local folder with the directories on the server.
All important data, such as keys, passwords, and tokens, should be stored in GitHub Secrets. They are not displayed in logs and are protected from accidental disclosure. If something goes wrong, the logs in the Actions tab will help you identify the problem. You can enable advanced debugging mode by creating a secret called ACTIONS_STEP_DEBUG with a value of true to see detailed messages about the execution of steps.
Everyone encounters errors in CI/CD, but most of the time they are easy to fix: a typo, a missing package, or an incorrect environment setting. GitHub allows you to restart only the failed steps, which saves time. Gradually, pipeline configuration becomes a habit, giving you control and confidence: you can focus on product development, knowing that the build will check the code and automatically upload it to the server. The main thing is not to rush, to configure step by step, to check and correct the process. When the pipeline runs like clockwork, you feel confident and free.
