Use this guide when your project is in a remote Git repository and has at least a few tests. Most code hosting services offer a built-in CI feature, so have access to your repository settings and know the commands that install, test and check your project locally.
Step by step
List your local checks
Write down the exact commands you run to install dependencies, run tests and check formatting or linting. Make sure each command works from a clean copy of the project. If you cannot run the checks reliably on your own machine, fix that first.
Create a basic pipeline
Use your code hosting service's CI feature to create a configuration file in the repository. Start with a pipeline that installs dependencies and runs your tests on every push and pull request. An AI assistant can draft the file, but check the syntax against the service's official documentation.
Add quality checks
Once tests run, add a formatter check and a linter so style problems and common mistakes are caught automatically. Consider adding a dependency vulnerability scan if your hosting service offers one. Add checks one at a time so failures are easy to understand.
Handle secrets safely
If your pipeline needs credentials, store them in the service's secret settings rather than in the configuration file. Give them the minimum permissions needed. Never print secrets in logs.
Protect your main branch
Turn on branch protection so changes can only be merged into the main branch when the pipeline passes. This stops broken code, including unreviewed AI suggestions, slipping through. Work on feature branches and merge through pull requests.
Keep the pipeline healthy
Fix failing checks promptly rather than disabling them. Keep the pipeline fast by running only what is useful, as slow checks get ignored. Review the setup every few months as your project grows.
Ready-to-use checklist
- Local commands documented
- CI configuration file created
- Tests running on every push
- Formatter and linter added
- Secrets stored in secure settings
- Branch protection enabled
- Pull requests used for merges
- Pipeline runs in reasonable time
Practical tips
- Add a status badge or check your pipeline results page regularly so failures do not go unnoticed.
- Pin the versions of your language and key tools in the pipeline so builds are repeatable.
- Run the same commands locally before pushing to save waiting for CI to fail.
Common problems
Tests pass on my computer but fail in CI.
The CI environment may have different versions, missing environment variables or a different operating system. Compare versions and settings, and make sure the project does not rely on files that exist only on your machine.
The pipeline takes too long.
Cache dependencies between runs if your service supports it and split slow tests into a separate job. Run the fastest checks first so obvious problems fail quickly.
Someone wants to disable a failing check to merge urgently.
Find out why it fails first, as it may be catching a real problem. If a temporary exception is truly needed, record why and fix the check promptly afterwards.