Glossary

A/B testing – a method of testing that uses two versions of the entity to be tested, such as a web page, to determine which of the two generates more interest. One version of the entity is the control and the other is the treatment. The two are identical except for a single variation. The control is the original version and the treatment has the modification. To use a web page as an example, the control is shown to some group of users and the treatment to another group of the same size. The two pages are monitored to see which generates the most clicks.

Agile – a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. The Agile Manifesto introduced the term in 2001.

Application lifestyle management (ALM) – a continuous process of managing the life of an application through governance, development, and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management. (Wikipedia)

Branch – a copy of a set of files in a different part of the repository that allows two or more teams of people to work on the same part of a project in parallel.

Build – preparing all the artifacts that will be run by the steps included in a stage. In other words, a build does more than compile the source code. It can also include activities such as copying files, references, and dependencies, including supporting files such as images and software packages, and signing assemblies.

Build agent – in terms of TFS, the build agent does the processor-intensive and disk-intensive work. This work includes getting files from and checking files into version control, provisioning the workspace, compiling the code, and running tests. Each build agent is dedicated to and controlled by a single build controller.

Build automation – the practice of triggering a build programmatically on the occurrence of some event, such as a check-in to the version control system. A common way to automate a build is to use scripting. A single command runs the entire build. An automated build compiles source code, packages the compiled code, and can also run tests, deploy the software to different environments, and create documentation.

Build controller – in terms of TFS, a build controller accepts build requests from any team project in a specified team project collection. Each build controller is dedicated to a single team project collection. Each build controller pools and manages the services of one or more build agents. It distributes the processor-intensive work (such as compiling code or running tests) to the build agents within its pool. The build controller processes the workflow and typically performs mostly lightweight work such as determining the name of the build, creating the label in version control, logging notes, and reporting status from the build.

Build definition – in terms of TFS, a build definition contains instructions about which code projects to compile, which additional operations to perform, and how to perform them.

Build machine – in terms of Team Foundation Server, a build machine is a computer on which you have installed and configured Team Foundation Build Service. The machine can be a physical machine or a virtual machine.

Build script – the commands used to create an automated build. Shell scripts, batch files, and PowerShell scripts are examples of ways to create a build script. There are also specialized build automation tools available such as MSBuild, Make, Ant, and Maven.

Build verification tests (BVT) – a group of tests used to determine the health of a build at a high level. Typically, these tests exercise the core functionality to help team members determine whether further testing is worthwhile. They are run after the daily build to verify that compilation of source code has been built successfully and is ready for further testing. Also known as smoke tests.

Change – see Version.

Commit stage – the stage where the binaries and artifacts are built.

Commit test – a test run during the commit stage of the pipeline.

Continuous delivery – a pattern to improve the process of delivering software. The deployment pipeline is seen as a series of validations through which the software much pass before it is considered "done." With CD, the implication is that software is always ready to be released. An actual release occurs in accordance with business needs, but any commit can be released to customers at any time.

Continuous integration – a pattern of merging development branches into the main branch. CI automatically occurs on a build server every time there is a commit to the revision control system, and automated unit and integration tests run after the code compiles. The pattern can be extended to include the automated run of other tests, such as functional tests.

Cycle time – a metric that shows the time from when you implement a change to when it is ready to release.

Defect rate – the inverse of MTBF. The number of defects found per unit of time.

DevOps – an approach to software development that advocates a collaborative working relationship between development and information technology (IT) operations. Its goals are to achieve high deployment rates and to increase the reliability and stability of the production environment. It is closely tied to the idea of continuous delivery.

Kanban – a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software team. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for on a kanban board. The board allows participants to see and pull work from a queue.

Kanban board – a visual tool that represents the steps that make up the development process, from the formulation of the idea to the delivery of the product or service to users. A common way to create a kanban board is to use a wall or board and sticky notes to represent each step. Kanban boards may be derived from the value stream.

Lead time – the time it takes from when you first consider making a change to when you can release it. Unlike cycle time, lead time includes activities not associated with development, such as evaluating whether the feature is worth implementing.

Lean software development – a subculture within the Agile community. It adapts principles used by Toyota for its manufacturing processes to software development.

Mean Time Between Failure (MTBF) – average length of time the application runs before failing.

Mean Time to Recovery (MTTR) – average length of time needed to repair and restore service after a failure. 

Merge – occurs when you take code from two branches and combine them into a single codebase.

Orchestration – the automated arrangement, coordination, and management of the release pipeline.

Pipeline – an implementation of the company's software release process. In continuous delivery, any instance of a pipeline supports the validation of a single version or change.

Pipeline stage – represents a set of related activities or steps that are taken during the software development process. Typical examples of pipeline stages are the commit stage, the automated acceptance test stage and the release stage.

Pipeline step – an activity that takes place within the context of a pipeline stage. Examples of pipeline stages are building the code and running tests.

Reverse integration – occurs when you merge code from a child branch to the parent branch.

Scrum – an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a traditional, sequential approach.

Smoke test – see Build Verification Test. 

System Center Virtual Machine Manager (SCVMM) – the portion of Microsoft System Center used to orchestrate virtual machine operations such as deployment, provisioning, snapshots and state management, across one or more physical Hyper-V host machines. 

Test-driven development (TDD) – a pattern that relies on very short development cycles: a developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the code to remove any duplication and improve the design. After every refactoring, the developer runs the tests again.

Unit test – tests a particular piece of code in isolation. Unit tests should not, for example, call a database or talk to external systems. This isolation allows unit tests to run quickly, so that you get immediate feedback on the build.

User acceptance testing (UAT) – tests that are often performed as the last phase of testing. During UAT, actual software users test the software to make sure it can handle required tasks in real world scenarios, according to specifications.

User story – describes a feature, service, or product in a way that is comprehensible to a nontechnical stakeholder. It contains a written description or short title, conversations about the story that flesh out the details of the story, and acceptance tests that document details that can be used to determine when a story is complete.

Value stream – all the steps required to take a product or service from its initial state to the customer. It includes all the people, processes, times, information, and materials that are included in the end-to-end process.

Value stream mapping – a flow diagram that shows every step in the value stream.

Version – a piece of software in a unique state. In this book, a change and a version are interchangeable terms. A change is some modification in the code or supporting artifacts that is checked in to version control. Because every change is a candidate to be released into production, it is also a version.

Version number – a unique number assigned to a version of software.

Version control system – a mechanism for maintaining multiple versions of files so that previous versions of modified files are still available. A principle of the DevOps methodology is that everything should be in the same version control system. This includes the standard files, such as source code, but should also include every artifact required to build the software. For example, build and deployment scripts, configuration files, libraries, and database scripts should all be in the version control system.

Visual Studio Lab Management – a TFS capability that allows you to orchestrate physical and virtual test labs, self-provision environments, automate build-deploy-test workflows, and encourage collaboration between testers and developers.

Visual Studio Team Foundation Server 2012 (TFS) – the collaboration platform at the core of Microsoft's ALM solution. TFS supports agile development practices, multiple IDEs and platforms locally or in the cloud. It provides tools to manage software development projects throughout the IT lifecycle. These tools include source control, data collection, reporting, and project tracking.

Wait time – the time in the development cycle when there are delays and no value is added.

Windows Installer (MSI) – a software component for Microsoft Windows computers that is used to install, maintain, and remove software.

Windows Installer XML (WiX) – a toolset that builds Windows Installer packages from an XML document.

XAP file – used to install apps on the Windows Phone 8. 

Next Topic | Previous Topic | Home | Community