What is the "best way" to develop software applications?

Summary

This video explains Trunk-Based Development (TBD) as an alternative to GitFlow, highlighting its benefits like rapid feedback, knowledge sharing, and small, manageable pull requests. The presenter discusses how TBD promotes continuous integration by merging code daily into the main branch, though it also comes with challenges such as the risk of breaking the build and the need for strong automated testing. The video covers strategies like feature flags and canary releases to manage production deployment and incomplete features. Overall, TBD is presented as an efficient, scalable approach for smaller teams, but larger projects may require additional processes to mitigate risks.

Takeaways

• 😀 Trunk-based development eliminates the need for multiple long-lived branches (e.g., Dev, Staging), focusing solely on the 'main' branch.
• 😀 Continuous integration (CI) is a core principle of trunk-based development, encouraging developers to merge pull requests (PRs) to the main branch multiple times a day.
• 😀 Rapid feedback is a key advantage of trunk-based development, as code conflicts are identified early, allowing teams to address issues sooner.
• 😀 Merging PRs daily results in smaller, more manageable code changes, reducing the risk of large, unreviewable pull requests.
• 😀 The approach promotes knowledge sharing within the team, as all developers are constantly exposed to each other’s work and can collaborate more easily.
• 😀 Potential downsides of trunk-based development include the risk of breaking changes affecting all developers, which requires a robust suite of automated tests (unit, integration, end-to-end).
• 😀 If breaking changes occur, the team can quickly identify and address the problem, but this requires effective communication and immediate action to mitigate downtime.
• 😀 Feature flags (or deployment flags) allow teams to deploy code to production without exposing unfinished features, ensuring that incomplete work doesn't impact end users.
• 😀 Canary releases offer a controlled deployment approach, where only a small percentage of users initially see new changes, helping to identify bugs in a production environment before a full release.
• 😀 The simplicity of the trunk-based development workflow is especially beneficial for smaller teams and projects, but larger teams or more complex projects may require additional processes like staging environments or release tags to reduce production risks.
• 😀 As projects grow, more processes may be added to reduce the chances of production issues, including pre-prod environments, release tags, and additional testing to ensure stable deployments.

Q & A

What is trunk-based development?

Trunk-based development is a software development approach where all developers work on the same main branch (often called 'main') and continuously integrate their code multiple times a day. The focus is on quick integration and feedback to avoid long-lived feature branches.

What are the main benefits of trunk-based development?

The main benefits include rapid feedback, faster detection of merge conflicts, and improved coordination between team members. It promotes continuous integration and knowledge sharing, as developers work closely on the same branch and review each other's code regularly.

How does trunk-based development differ from Git flow?

In trunk-based development, developers work directly on the main branch, while Git flow involves multiple branches (e.g., 'feature', 'develop', 'staging'). Trunk-based development encourages more frequent merges and integration, whereas Git flow may involve longer cycles of working in isolated feature branches before merging.

What are the potential risks of trunk-based development?

One risk is that merging bad code or bugs into the main branch can break the work of the entire team. Since everyone is continuously pulling from the main branch, any error introduced could affect everyone, creating delays until the issue is resolved.

How can automated tests help mitigate the risks in trunk-based development?

Automated tests, including unit tests and integration tests, are crucial for catching bugs before code is merged into the main branch. These tests act as a safety net, ensuring that only working code is integrated, reducing the risk of breaking other developers' work.

What is the role of pull requests (PRs) in trunk-based development?

In trunk-based development, PRs are used to integrate changes into the main branch. Developers open PRs daily to merge their changes, which are reviewed and tested to ensure quality. The goal is to keep PRs small and manageable for easy review and quick integration.

How does trunk-based development promote knowledge sharing?

By having developers work on the same branch and merge changes regularly, trunk-based development facilitates communication and knowledge sharing. Developers stay informed about each other's work, reducing the likelihood of duplicated effort and fostering collaboration.

What challenges can arise when deploying code multiple times a day in trunk-based development?

Deploying code multiple times a day can lead to unfinished features being deployed to production, which can confuse users or lead to issues. Features that aren't fully completed may be visible to users, requiring a strategy like feature flags to control when certain features are visible.

What are feature flags, and how do they work in trunk-based development?

Feature flags are used to enable or disable certain features in production without deploying new code. They allow teams to deploy incomplete features to production while controlling who can access them. This is crucial in trunk-based development, where rapid deployments can lead to unfinished features being pushed live.

What is the relationship between deployment strategies and trunk-based development?

Trunk-based development encourages fast, continuous deployment of code to production. The deployment process is often automated using tools like GitHub Actions, Jenkins, or CircleCI. This ensures that every change is quickly tested and deployed, reducing the time between code changes and production updates.