Developing for integrity

Last updated: Nov 3, 2026

This section describes all the practices of the development cycle of Fluid Attacks that give it a high integrity level.

Monorepo

Fluid Attacks has one Git repository for all its applications. With this approach, and not with many smaller repositories, Fluid Attacks gets these results:

Centralized source of truth: All the information about the application is in one place.
Centralized knowledge: Teams have full knowledge of the application, because they work in the same repository.
Standardization: It is easier to standardize a project (folder structure, naming conventions, and other conventions) when all the team works in one repository. It is not necessary to duplicate work or synchronize repositories.

As the "Everything as code" article says, Fluid Attacks tries to keep as much material as possible versioned in its Git repository. The source code is the only variable that affects an application. Thus, application integrity depends on a healthy source code.

Governance model

Internal contributions drive the repository of Fluid Attacks. The development lifecycle of Fluid Attacks follows a "most recent developer is responsible" model. This model gives clear ownership and support boundaries. It also prevents burnout, because the accountability moves as the code changes. In this framework, technical information goes up and business vision goes down. The CTO has the ultimate responsibility and the final decision authority for all the ecosystem.

Infrastructure as code

All the infrastructure of Fluid Attacks is written as code and versioned in its Git repository. Fluid Attacks can deploy this code anywhere. The code has all the properties of other source code, for example, auditability, history, and revert capabilities.

Regenerative infrastructure

Because its infrastructure is written as code, Fluid Attacks can create it again each day. The daily regeneration of the infrastructure gives these advantages:

It removes all injected Trojans or malicious scripts.
New servers every 24 hours prevent availability and performance issues from memory leaks and resources that are not released.
Fluid Attacks can deploy its infrastructure from zero to production with an automated process.

Immutable infrastructure

The infrastructure code is auditable. The only way to change the infrastructure is to change this code. This gives full transparency on what changed, when, and who changed it. Also, administrative protocols such as SSH and administrative accounts are not necessary.

Continuous integration

Fluid Attacks runs an Application Build Process for each change that a developer wants to add to the source code of the application through a merge request. The Application Build Process includes steps such as these:

Exploit tests
Linting tests
Compilation tests
Unit tests
End-to-end tests
Commit message tests
Commit deltas tests

Fluid Attacks always builds and tests everything. Thus, it can guarantee that each change complies with the quality standards of the application.

Peer review

Fluid Attacks knows that it cannot automate all the steps of a build process, especially some tests. Thus, a change to code that reaches the clients of Fluid Attacks needs a peer review before its merge request can go to production. Reviewers usually evaluate code quality, commit message coherence, and other semantic properties of the change. (The reviewer must be an approver of the code that changes. The reviewer cannot be the author or a person who pushed code to the merge request.)

Two cases go to production without a peer review:

Trusted authors: Engineers with a very low error rate over a long record, when no other person pushed code to their merge request
Code that no client uses yet: For example, a component in development, or a migration that is not complete

With or without a peer review, each merge request needs a successful pipeline and an automated review before it merges.

In peer reviews, product teams also discuss philosophies, standards, and future plans for the application. This is an ideal space for senior developers to guide junior developers.

Continuous deployment

Fluid Attacks runs an automated build process for each change, and it also runs an automatic deployment process. When a merge request is merged, an additional Continuous Deployment (CD) pipeline starts. This pipeline automatically deploys a new production version from the new source code.

Trunk-based development

Fluid Attacks uses trunk-based development to keep only one long-term trunk branch. That branch is the source of truth about the code that runs in the production environments.

Micro-changes

The merge requests of developers cannot be larger than 250 deltas of code. A delta is a removed line of code or an added line of code. These are some advantages of micro-changes:

Merge requests are small, and peer reviewers can review them easily.
Because changes are smaller, it is more difficult to add critical bugs to production.
If a deployment fails, it is easier to find the error in those 250 deltas.
Developers go to production many times each day. Thus, the code does not become old.
Users of the application see it change each day.

Short-lived branches

Developers work on short-lived branches. The name of a branch has one or two lowercase words, with an optional hyphen between them (for example, feature or john-feature). When they develop a part of the code (a maximum of 250 deltas), they run the CI phase, create a merge request, and ask for a peer review when the change needs one. If all goes well, their branch merges to the trunk branch, their changes go to production, and their short-term branch is deleted.

Isolated and sudo-less dependencies

Some dependencies of Fluid Attacks do not require OS libraries such as libc. Fluid Attacks builds them fully from scratch. This guarantees full reproducibility.

Also, these dependencies do not require administrative privileges such as sudo. Fluid Attacks builds them fully in user space. This highly decreases the possibility of compromised OS core files.

No dependency auto-update

All external dependencies are pinned to a specific version. This is closely related to the immutability property. To update a dependency, a developer must do these steps:

Change the version in the source code.
Run all the CI tests with the new dependency version.
Get a peer review when the dependency is in code that reaches clients.

If the change passes all the tests and has the reviews that it needs, the system automatically deploys a new production version with the updated dependency.