There is a convenient myth that software development is about coding, testing, and releasing, and nothing else. In practice, developers, testers, and system administrators often spend an extraordinary amount of time doing work unrelated to coding, testing, and releasing. Managing requirements, building software, deploying development environments and test environments, managing test data, managing production systems, and reporting status all take time away from the work of coding, testing, and releasing. To reduce the time spent on these ancillary activities, software teams need The Big Red Button.
The Big Red Button is the idea that everything not directly related to coding, testing and releasing should be automated to the greatest extent possible. So when a build needs doing, someone presses The Big Red Button and the build is done. When the team needs a new test environment, someone presses The Big Red Button, and a new test environment appears. When it is time to release to production, someone presses The Big Red Button and the release happens.
Software requirements
For requirements, The Big Red Button means that there is one, and only one, version of every requirement that everyone on the team can read. Multiple versions of multiple Microsoft Word documents on a shared network drive are not acceptable.
A wiki is an excellent place to keep requirements. Most modern wikis have searching and tagging features, and most modern wikis keep a history of
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
each page, so no information is ever lost. And a wiki tweaked for issue management is an even better solution, because it allows the team to keep track of the status of each requirement as well.
CI systems and code
There is no longer any excuse for software development teams not to run some sort of continuous integration (CI) system for their code in progress. Upon checking in code to a central shared repository, a CI system will build the entire code base from scratch, run unit tests on that code, and report the status of each build and each test to a particular place for everyone to see. For code, The Big Red Button is built into the system and starts to work the instant that new code is checked in.
CI systems may also deploy particular development or test environments, run integration tests or user interface (UI) tests or performance tests. They may report various kinds of status to other parties.
Excellent CI systems exist for just about every modern programming language. And CI systems today are so well understood that there is no reason not to build them even for languages that are in use but are not so modern, like COBOL or Fortran. A few simple scripts in such systems will serve as a perfectly useful CI system.
Automating application testing
Test environments are typically more complex than development environments. Test environments require a whole cohesive system, complex test data, management of certain parameters and settings in the system. Test environments may need one Big Red Button or several.
When a tester needs a new test environment, she should be able to just push The Big Red Button and have a new test environment. When a tester needs fresh test data, she should be able to press the Big Red Button and get fresh test data. Testers need a Big Red Button to run automated regression tests reliably.
Finally, testers need a Big Red Button to tell everyone when the testing is finished.
Automating application release
Deploying to production should require nothing more than pressing The Big Red Button.
It is interesting to see the move in the software development community toward the idea of "continuous deployment" and "release on demand". Continuous deployment means that new features are implemented in production instantly upon the software development process being completed for each feature, without the need for human intervention.
Much like CI, for continuous deployment, the Big Red Button is built into the system: the instant that a feature is completed, it is available to real users.
Software project status reporting
People on a software development team should be busy coding, testing, and releasing. Time spent reporting status is time spent not coding, testing and releasing.
A Big Red Button is required so that anyone interested can see the status of each part of the project. Anything else takes time away from the most important work of the project.
Automate, automate, automate processes
Automating business and software processes is something that computers do very well. Every aspect of software development work that is not directly concerned with the creative efforts of the people on the team should be automated, so that people on the team can spend their time doing creative work instead of tedious and fragile maintenance activities.
From CI to test environments to test data to regression testing to performance testing to deployment: If your team does not already have Big Red Buttons in place, start building them now.
This was first published in October 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation