DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report

The Build Monkey Antipattern

Kief Morris user avatar by
Kief Morris
·
May. 29, 12 · Interview
Like (0)
Save
Tweet
Share
13.85K Views

Join the DZone community and get the full member experience.

Join For Free
a common pattern in software development teams is to have a person who owns the build system. this may be a deliberate decision, or it may evolve organically as a particular team member gravitates towards dealing with the build scripts, automated testing and deployment, etc. while it’s normal for some team members to have a deeper understanding of these things than others, it’s not a good idea for the knowledge and responsibility for the build to become overly concentrated in one person.

i prefer the term build gorilla myself the build system should be looked at as a module or component of the software application or platform being developed, so the philosophy taken towards code ownership apply.

if a single person owns the build system, everyone else becomes dependent on them to fix issues with it, and to extend it to meet new needs. there is also a risk, especially for projects which are big enough that maintaining the build system becomes a full time job, that a bit of a siloed mentality can develop.

if developers have a poor understanding of how their software is built and deployed, their software is likely to be difficult and costly to deploy. on the flip side, if build and test tools are implemented and maintained entirely by people who don’t develop or test the software, it isn’t likely to make the life of those who do as easy as it could be.

in the past few months i’ve taken on a role which is largely focused on this area, and have been helping a development team get their build and delivery system in place. pairing with developers to implement aspects of the system has worked well, as has letting them take on the setup of particular areas of the build and test tooling. this follows what martin fowler calls “weak code ownership”, allowing everyone to take part in working on the build and test system.

special attention is needed for stages of the path to production as they get further from the developer’s workstation. developers are keen to optimize their local build and deployment, but can often be fuzzy on what happens when things are deployed in server environments. this is exacerbated when the platforms are different (e.g. developers working on windows, code deployed on linux).

even without platform differences, developers understandably focus on the needs of their own local build over those of production system deployment. this is natural when server deployment is not a part of their daily world. so the best way to compensate for this is to keep developers involved in implementing and maintaining server deployment.

driving the implementation of the build and deployment system according to the needs of business stories has also been useful. so rather than setting up tooling to test parts of the system that haven’t been developed yet, wait until the design of the code to be tested starts to be understood, and the code itself has actually started being developed. this helps ensure the tooling closely fits the testing and deployment needs, and avoids waste and re-work.

Build (game engine) Software development

Published at DZone with permission of Kief Morris, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Best Practices for Setting up Monitoring Operations for Your AI Team
  • Integrating AWS Secrets Manager With Spring Boot
  • Securing Cloud-Native Applications: Tips and Tricks for Secure Modernization
  • Beyond Coding: The 5 Must-Have Skills to Have If You Want to Become a Senior Programmer

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: