The purpose of the Brownfield Dev project is to showcase patterns that empowers teams charged with care and feeding for a system with an outdated architecture.
GitLab is a great tool that has some strong opinions about architecture, branching strategy, and security controls. These opinions are centered around web-based applications, microservices, cloud native, small teams, and groups of repos.
Git is complicated and the branching, forking, tagging, and other options make it possible for developers to collaborate, but the lack of structure creates the need for additional constraints. GitLab serves as an enabling, organizing, and constraining force to let people with different roles work on the same codebase with as little complexity as possible.
Many GitLab clients are large organizations, some private sector, some pubilc sector, who cannot simply abandon old systems and start fresh with a NodeJS microservice on MogoDB. There are some example templates floating around that show one aspect or another of how GitLab can be used to build or deploy an older app. These are useful if the rest of the plan is sound, but in isolation do not provide enough context.
The format for this project is to create related elements to back up a central story, but make the central story highly relevant to a specific client or project in the real world. This will include peripheral things like organizational issues (security constraints, change review boards, IV&V, etc) and project-related things like splitting up a monolith or moderinizing components.
Attention will be payed to the whole design:
- Group structure
- Project features
- Repo architecture
- Branching and Tagging strategies
- GitLab permissions
- CI pipelines (build, test, deploy)
- Runner deployment
- IAC, coordination, or deployment projects
When the pattern is worked out and the team is using it, articles will be made to relate the technical solution to various aspects of working on a brownfield application.
The term comes from “greenfield” being a “nice fresh new clean” sort of effort that has endless possibilities and no prior decisions need to be considered.
brownfield is the opposite.
Applications that are considered brownfield are typically older. Designed before the newer stacks
and patterns were established. Interestingly enough, even Ruby on Rails apps are starting to feel
brown at this point.
I’d actually recommend considering any application that is in production to be Brownfield due to the inflexibility that comes with a high uptime SLA. Applications get browner after they’ve passed between owners or have been officially consigned to “operating and maintenance” contracts with reduced resources.
A brownfield team typically has:
- established, old processes
- actions and procedures defined by how things were done in the past
- attrition of early direction-setting folks
- strong central command and control structure
Bringing scrutiny to the structure, roles, and activities in the team may play into some of the changes discussed in this project.
Teams are much easier to rejouvinate than applications. Improving internal processes and collaboration is easy and fun with quick results. A larger team that has more varied intrinsic goals becomes much more difficult to rejuvenate.
Any organization that has not embraced the
learning organization approach will inevitably become
brownfield due to the way bureaucracy tends to work. As risk aversion overwhelms growth, the
individual contributors tend to leave and the organization stagnates. The board sees the slowdown
and in order to prevent the decline from overwhelming shrinking margins, they offshore or outsource
or layoff or take some other destructive action.
In the public sector, it’s a little different. Your organization is hundreds of years old and under control of some oversight committee in congress. There is likely no way to revolutionize the organization as a whole. The best we can shoot for is loosening the reins a bit and enabling the smaller organization to do good things.
The last aspect of this project is going to focus on the reader. We can all contribute more by using techniques for better time management, better messaging and communicating, problem definition, and others. These will likely be references to existing works like Own the Room, Deep Work, or other relevant books, articles, studies, and techniques.