There are different work environments (development, staging, production) with automatic deployment processes (CI/CD) on platforms like GitLab or GitHub. But do you really need all this?

As I always say, it depends. If many people are working on a project, it’s good to have some control, and for that, there must be processes that guarantee the platform's stability and reliability. But what if it’s a small product where few people are working? What if it's your side-project? You probably don't need all this complexity, allowing you to work much faster and easier.

Nowadays, computers are very powerful and allow you to run tests and deployments from your local machine, which saves you from having to pay for or maintain these systems. It’s like I mentioned in my last post about deploying on Kubernetes or a VPS. Both options are good and will work for you, but depending on your needs, one may be better than the other.

Lately, I aim to be efficient when working on any project or product. Each will have its specific needs: in some, I maintain systems with pipelines that allow us to standardize certain processes and ensure proper functioning, enabling continuous deployment, while others allow me to maintain much simpler, faster, cheaper, and more efficient options.

Taking advantage of my knowledge of more complex architectures, I set myself the task of simplifying my own work when it comes to side-projects or small products with a small team. In this case, I simply have a script that allows me to run a local pipeline to perform the different actions and, in many cases, you can even deploy your environment to production.

A small team can move faster

When the team is smaller, we can afford certain liberties that facilitate faster development. With fewer people involved, processes can be more relaxed, as long as there is a solid culture and values that validate good practices. Fewer environments, fewer processes, and fewer pieces to maintain allow us to focus our time on what truly matters: our product.

To ensure reliability, you can always use tests or technologies like Docker, which allow you to create identical environments. Often, you won’t need complex test environments, as a product engineer should be able to develop and validate their functionality and deploy it directly to production. Additionally, these complex environments require maintenance time, but in the end, time is both the scarcest and most valuable resource, although we often forget this.

And if you really need it, remember that you can always set up a continuous integration system (CI/CD).

If you work alone, keep it as simple as possible

In my case, I maintain several projects by myself. Some of them have CI/CD to ensure certain processes or to take advantage of tools already created by other teams. However, other projects only have a script for building and deploying, and so far, this works great for me.

For example, this blog is a project with Next.js, hosted in a GitHub repository, which I deploy from local to production. I use a VPS where I copy the Node files and install the dependencies. I don’t use Docker since there are no complex or problematic dependencies, and despite working with an ARM processor Mac and the server being x86, I haven’t had any issues. I have some tests to ensure the "happy paths" and deploy to production via a bash script. This way, I don’t waste time maintaining and creating a pipeline, nor do I have to pay for additional servers or maintain a Docker image registry.

Conclusion

I increasingly realize that the simpler, the better, although we tend to complicate things ourselves. Keeping simplicity in processes allows focusing on the essential, avoiding the overload of unnecessary tools and configurations. This philosophy of simplicity is especially valuable when you work alone or with a small team, allowing you to move faster and with fewer obstacles.