$
cd ../posts
My CI Approach
Sep 21, 20263 min read
My CI Approach

I would like to start my posts series with a topic that I think is often overlooked by new developers who are just starting their software development journey and experienced developers as well.

So while there is a set of industry-standard CI practices that are considered good, these often include:

  • Unit / E2E tests
  • Linting
  • Type checking
  • Build runs

I think it would be a good thing for me to share some practices I find useful in the projects that I worked on (besides the ones that I mentioned earlier).

1. AI-supported code reviews

While there can be a controversy around using AI for reviews, in my experience, every project that had AI enabled for reviews, whether it used Claude, Codex, etc. was beneficial in a couple of ways:

  • It does manage to spot some things that people miss, either because they are tired, not so experienced or just not so interested in conducting a review.
  • It saves a lot of time because developers often need to look through the code, then run the project to see if all is good. By using AI we can sometimes skip the first step and move on to the next one.

But there are always some trade-offs that come with it:

  • Sometimes AI suggestions can prolong the PR merging process because it can have different ideas on how the feature should be implemented every time the code check runs.
  • A lot of suggestions can be irrelevant but developers on your team can still try to address every issue that an LLM points out.

Considering all this, I have to say that I don’t think that developers can be replaced and I don’t think they should not engage in the reviewing process anymore. I am just saying that it can always be helpful to have such a tool.

2. Deployment previews

They can be beneficial in terms of QA.

Without them, a lot of PRs can be just merged into dev / staging environment, they are not always checked by QA and / or PM.

When it comes to checking PRs by developers it always takes an additional 2-3 minutes to stash / commit their work, pull the changes, install packages and run the project. It is a long and repetetive process which can be annoying for a lot of us.

3. Using Fallow for JS / TS projects

I find it really useful for a couple of reasons:

  • Detects code complexity
  • Prevents dead code & duplications
  • Respects React client / server boundaries
  • Reports are so good and readable for both humans and LLM that it makes it much easier to address detected issues

But there is also an issue that you should be aware of:

  • It needs an additional config because, for example, it often can detect something like CSS imports as duplications and that can be annoying when it comes to a refactor / clean-up

4. Automate everything that is possible

Do you feel that some processes in your company are monotonous and are taking too much time? Just automate it! Both you and your company will be happy because saving time = saving the company money.

Project setup