The Developers' Glossary of DevOps

DevOps would not be what it is without a language that is all its own. It helps to get clear on what we mean when we use developers' jargon to describe important development operations practices. As you continue to bridge process and technology, familiarity with these terms will help you understand the spirit, not just the law, of DevOps. If you are still learning exactly what DevOps is, be sure to read "A Quick Guide to Development Operations."

Continuous Integration

(Fowler, 2006): a software development practice where members of a team integrate their work frequently, usually at least daily, and even multiple integrations per day. Each integration is verified by an automated build (including test) to quickly detect errors. 

Pair Programming

(Williams & Kessler, 2003): style of programming in which two programmers work side by side at one computer, continually collaborating on the same design, algorithm, code, or test. DRIVER- types and writes the design NAVIGATOR- observes the driver and looks for defects 

Refactoring

(Fowler, 2014): the process of changing a software system in such a way that it does not change the external structure of the code, only the internal. When you refactor, you are simply improving the design of the code after it has been written. 

Single Command Build

(Biedenharn, personal communication, October, 2018): describes the goal of automating the process of turning the code into a fully functional program so that it functions with a single command, thus not requiring a multi-step procedure. 

Single Source Repository

(Fowler, 2006): allows teams to keep the main project codebase in one easy-to-access location. This allows for easy version control; and, for any new team members to get up and running easily. 

Technical Excellence

managing constraints on software development via techniques, individual skills, and practices as a team. Generally, this includes test-driven development, collective code ownership, continuous integration, “egoless programming” (Gerald Weinburg), and a personal commitment to self-improvement in pursuit of software development as a craft. 

Test-Driven Development

(Beck, 2014): development driven by automated tests. 1. Red: Write a test that doesn’t work. 2. Green: Make the test work quickly. 3. Refactor: Clear up all duplication made in process to make the test work. 

Unit Testing

testing the smallest units possible to prove what was written is true. TYPES OF UNIT TESTING FRAMEWORKS: • Xunit - C# and .Net • Junit - Java • Nunit - .Net • PyUnit - Python • Cppunit - C++ • Ocunit - Objective C

Interested in learning more? Become a Scrum Alliance® Certified Scrum Developer.

REFERENCES Beck, K. (2014). Test-driven development by example. Boston: Addison-Wesley. Fowler, M., Beck, K., Brant, J., Oodyke, W., & Roberts, D. (2014). REFACTORING: Improving the design of existing code. Reading, MA: Addison-Wesley. Fowler, M. (2006, May 01). Continuous Integration. Retrieved from martinfowler.com Williams, L., & Kessler, R. (2003). Pair programming illuminated. Boston, MA: Addison-Wesley.