Good practices that make a difference #2 📝

This is the second post in a series about good practices that I learned during my journey, both at work and in recruiting processes, as well as at college and personal or community projects.

Check out the first post clicking here.

Summary

• 1. Git Flow
• 2. Secrets
• 3. Organizing a project

1. Git Flow

This is an extensive subject, so we will try to summarize its main points, but I highly recommend looking into this topic in more depth later, as well as all the other topics I have introduced you to.

Git Flow is a workflow model for Git¹ repositories, being a great ally in medium or large projects, or even in smaller projects with more than one person working, as it helps us organize and standardize the structure of our repository/Git project.

To adopt Git Flow, you must have at least two of the first main branches below:

• main²: main branch containing all stable and previously approved changes in other branches.
• develop²: intermediate branch where changes are made (normally only in small projects) or merged from other temporary branches.
• hom: intermediate branch for the purpose of approving changes, before sending them to main.
• stage: less common intermediate branch, also for approval purposes, however, connected to an environment with configurations similar to those of the production environment, for example, in cases of big commercial web applications.

And finally, the temporary branches, where changes are normally developed:

• feature/feature-name: branches where certain features are developed and then merged into the develop branch.
• fix/fix-name: branches where corrections are developed for bugs found or reported by users.
• hotfix/fix-name: branches where urgent fixes are developed, for which it is normally not possible to wait for the entire delivery flow of a new version.
• release/release-name: branches where we merge all planned changes for a given version of the project, normally used with some continuous integration automation.

To conclude, in Git Flow we conduct work on temporary branches and then merge everything into the develop branch, optionally merging for testing and approval purposes into the stage, hom, or even the develop branch itself, and finally, merging into the main branch, making the changes available in production.

Another interesting point about Git Flow is that it helps us to better structure our continuous integration (CI) tools, however, it is not recommended for continuous delivery (CD) cases, as it would generate the need for long-term or even permanent branches (in addition to the 2 or 3 main ones).

2. Secrets

This is all confidential data used in applications that should not be publicly accessible, such as passwords, API keys, tokens, etc.

But how can we hide them in our projects? We normally use environment variables (or just env vars) and tools specialized in managing and securely hosting secrets, such as AWS Secrets Manager.

Operational systems have environment variable managers, but it is common to also see the use of files such as .env³ to facilitate the use of project-specific secrets:

DB_HOST=172.0.0.1
DB_PORT=5432
DB_USER=admin
DB_PASSWORD=123

Many technologies natively have functions or methods for reading and manipulating environment variables, however, in some cases it is necessary to use third-party libraries, as was the case with Node.js, but today since version 20.6.0, natively supporting reading .env files. For example, given the .env file above and the code below:

const DB_HOST = process.env.DB_HOST,
      DB_PORT = process.env.DB_PORT,
      DB_USER = process.env.DB_USER,
      DB_PASSWORD = process.env.DB_PASSWORD;

...

It would be enough to start our project with the following arguments in the terminal, so that the Node.js application would execute loading the secrets contained in the .env file:

node --env-file=.env file_name.js

3. Organizing a project

As we already saw in the first post, each person, technology, team, or company can have patterns/conventions for organizing projects, folders, files, etc.

It is important to know the most used patterns in the area or technology you use, as they are normally described in articles or even in the documentation itself, such as in the following documentation for Next.js or FastAPI.

---

That's it for today, I hope you like it and for any feedback or constructive discussion, see you on social media and here in the comments! 🎉

---

1. It is quite common to see confusion regarding Git, GitHub, GitLab, etc. But it is important to remember that Git is the versioning tool, while GitHub and alike are secure cloud hosting and management platforms for these Git repositories/projects. ↩

2. Nowadays, the naming pattern master, slave, among others, is no longer used, due to its racist connotation and in support of the "Black Lives Matter" movement, starting with GitHub, and then, other companies adopting the new pattern for the same reasons. ↩

3. Files that contain secrets such as .env, by their nature must be included in the .gitignore file in case of uploading to remote repositories, otherwise anyone with access to these repositories would have access to them, even if they did not have authorization for using it. ↩