Category: Concept & Definition

What is HTTP (HyperText Transfer Protocol)

by scmgalaxy KConcept & DefinitionLeave a Comment on What is HTTP (HyperText Transfer Protocol)

Short for HyperText Transfer Protocol, the underlying protocol  used by the World Wide Web. HTTP defines how messages are formatted and transmitted, and what actions Web servers and browsers  should take in response to various commands. For example, when you enter a URL in your browser, this actually sends an HTTP command to the Web server directing it to fetch and transmit the requested Web page.

The other main standard that controls how the World Wide Web works is HTML, which covers how Web pages are formatted and displayed.

HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it.

Tagged : / / / /

Berkeley Internet Name Domain(BIND)

by scmgalaxy KConcept & DefinitionLeave a Comment on Berkeley Internet Name Domain(BIND)

Abbreviated as BIND, Berkeley Internet Name Domain  is the most common implementation of the DNS protocol on the Internet. It’s freely available under the BSD License. BIND DNS servers are believed to be providing about 80 percent of all DNS services. BIND was developed by the University of California at Berkeley. The most current release is BIND 9.4.2, and from Version 9 on wards it supports DNS SEC, TSIG, IPv6 and other DNS protocol enhancements.

Tagged : / / / /

What is DNS (Domain Name System)

by scmgalaxy KConcept & DefinitionLeave a Comment on What is DNS (Domain Name System)

Short for Domain Name System (or Service  or Server), an Internet service that translates domain names  into IP addresses. Because domain names are alphabetic, they’re easier to remember. The Internet however, is really based on IP addresses. Every time you use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. For example, the domain name www.example.com might translate to 198.105.232.4.

The DNS system is, in fact, its own network. If one DNS server doesn’t know how to translate a particular domain name, it asks another one, and so on, until the correct IP address is returned.

Tagged : / / / / /

What is SSH(Secure Shell)

by scmgalaxy KConcept & DefinitionLeave a Comment on What is SSH(Secure Shell)

SSH Secure Shell provides users with a secure, encrypted mechanism to log into systems and transfer files; it can be viewed as a secure replacement for FTP.

Developed by SSH Communications Security Ltd., Secure Shell is a program to log into another computer over a network, to execute commands in a remote  machine, and to move files from one machine to another. It provides strong authentication  and secure communications over insecure channels. It is a replacement for rlogin, rsh, rcp, and rdist.

SSH protects a network from attacks such as IP spoofing, IP source routing, and DNS spoofing. An attacker who has managed to take over a network
can only force ssh to disconnect. He or she cannot play back the traffic or hijack the connection when encryption is enabled.

When using ssh’s slogin (instead of rlogin) the entire login session, including transmission of password, is encrypted; therefore it is almost impossible for an outsider to collect passwords.

Tagged : / / / / /

Agile Software Development Methodology

by scmgalaxy KConcept & DefinitionLeave a Comment on Agile Software Development Methodology

What is Agile Software Development Methodology?

Agile development practices increase the velocity at which software teams deliver customer value by improving everyone’s visibility into project features, quality and status.

BROAD DEFINITION: 
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

General Definition
There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing.

 

image

Specification

This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration’s requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

 

image

Some of the principles behind the Agile Manifesto are:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily cooperation between business people and developers
* Face-to-face conversation is the best form of communication (co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

Reference: http://en.wikipedia.org/wiki/Agile_software_development

Tagged : / / / / / /

Definition of Configuration Management

by scmgalaxy KConcept & DefinitionLeave a Comment on Definition of Configuration Management

Software CM is a discipline for controlling the evolution of software systems. Classic discussions about CM are given in texts such as [6] and [8]. A standard definition taken from IEEE standard 729-1983 [42] highlights the following operational aspects of CM:

  • Identification: an identification scheme reflects the structure of the product, identifies components and their types, making them unique and accessible in some form.
  • Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product.
  • Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product.
  • Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that the product is a welldefined collection of components.

The definition includes terminology such as configuration item, baseline, release and version. When analyzing CM systems—automated tools that provide CM—it becomes evident that these incorporate functionality of varying degrees to support the above definition. Some CM systems provide functionality that goes beyond the above definition though. This is due (among other reasons) to the recognition of different user roles, disparate operating environments such as heterogeneous platforms, and programming-in-the-large support such as enabling teams of software programmers to work on large projects synergistically. To capture this extra functionality, it is necessary to broaden the definition of CM to include:

  • Manufacture: managing the construction and building of the product in an effective and optimal manner.
  • Process management: ensuring the carrying out of the organization’s procedures, policies and lifecycle model.
  • Team work: controlling the work and interactions between multiple users on a product.

In summary, the capabilities provided by existing CM systems encompass identification, control, status accounting, audit and review, manufacture, process management and team work.

Tagged : / / / / / / /

Features in TFSC are fairly standard among SCC tools

by scmgalaxy KConcept & DefinitionLeave a Comment on Features in TFSC are fairly standard among SCC tools

Some of the features in TFSC are fairly standard among SCC tools:

  • Workspace creation
  • Workspace synchronization
  • File checkout
  • Overlapping checkout by multiple users of the same file
  • Atomic change-set check-in
  • File diffs
  • Automated merge
  • Code-line branching
  • File-set labeling
  • User management and security

What really sets TFSC apart from the competition is its powerful merging and branching features

Tagged : / / / / /

Merging Functionality in TFSC

by scmgalaxy KConcept & DefinitionLeave a Comment on Merging Functionality in TFSC

The merging functionality in TFSC is centered on the following typical development scenarios:

  • Scenario 1: The catch-up merge— The user wants to merge all changes from a source branch that have not yet been migrated to the target branch. The source and target can be a subtree or an individual file/folder.
  • Scenario 2: The catch-up no-merge— The user wants to discard nonmerged changes in the source branch from the set of candidate changes for future merges between the specified source and target.
  • Scenario 3: The cherry-pick merge— The user wants to merge individual change sets from the source branch to the target branch. Changes introduced to those files prior to the specified change set should not be migrated.
    • The user can specify the change sets to merge with a change set number.
    • The user can specify individual file revisions to merge between the source and target.
  • Scenario 4: The cherry-pick no-merge— The user wants to discard a single change set from the list of all possible changes to merge between the source and target so that this change set never appears in the list of candidates for a cherry pick merge.
  • Scenario 5: Merge history query— The user wants to know whether the specified change set has been merged into the target branch. If it has, the user wants to know what change set the merge was committed in. The user also wants to know if part of the change set has been merged, but not all.
  • Scenario 6: Merge candidate query— The user wants to obtain a list of change sets that have been committed to a source branch but have not yet been migrated to the target branch. From this list, the user selects change sets to migrate with a cherry pick merge.

How TFSC Addresses the Scenarios

TFSC merging is designed to provide users with an extremely powerful and flexible tool for managing the contents of branches. Merges can be made into a single file or into a tree of related files. Merges can also migrate the entire change history of the specified source files or an individual change set or revision that might contain a specific fix or feature that should be migrated without moving other changes from the source in the process. Merging the entire change history prior to a given point in time is known as a catch-up merge (Scenarios 1 and 2), whereas selecting individual change sets or revisions to merge is known as a cherry-pick merge (Scenarios 3 and 4). The merge command also allows users to query for merge history and merge candidates and perform the actual merge operation.

TFSC presents merge history and candidate merges as a list of change sets that have or can be migrated between a source and a target branch. Merges can be made to a subset of files in a change set, creating a situation in which a partial change set has been merged. In this case, TFSC represents the partial state of the merge and allows the user to finish merging the change set later.

Merges are pending changes in TFSC. The user can choose to perform several merge operations within a workspace without committing changes following each merge. All these merges can be staged in the user’s workspace and committed with a single check-in as a single change set. In addition, the pending merge operation can be combined with the checkout and rename commands to interject additional changes to the files that will be committed with the merge.

Hopefully you followed this summary and are still with me. Now let’s go into how branching works in TFSC.

Reference: The Build Master: Microsoft’s Software Configuration Management Best Practices

Tagged : / / / / /

Branching in TFSC

by scmgalaxy KConcept & DefinitionLeave a Comment on Branching in TFSC

Branching in TFSC

Branching is the SCM operation of creating an independent line of development for one or more files. In a sense, branching a file results in two identical copies of the original file that can be modified as desired. Changes in the old line are not, by default, reflected in the new line and vice versa. Explicit operations can be performed to merge changes from one branch into another.

There are many different reasons for branching and many different techniques to accomplish it. In the most common scenarios, branching is reasonably simple, but branching can become complicated. A complex system with lots of branched files can be hard to visualize. I recommend mapping this with a visual product (such as Visio) so that the picture is clear.

Following are a handful of scenarios in which branching is interesting. Any SCM team should adopt these definitions.

Release Branching

We’ve been working on a Version 1 release for a year now, and it is time to begin work on Version 2. We need to finish coding Version 1—fixing bugs, running tests, and so on—but many of the developers are finished with their Version 1 work (other than occasional interruption for bug fixes) and want to start designing and implementing features for Version 2. To enable this, we want to create a branch off the Version 1 tree for the Version 2 work. Over time, we want to migrate all the bug fixes we make in the process of releasing Version 1 into the Version 2 code base. Furthermore, we occasionally find a Version 1 bug that happens to be fixed already in Version 2. We want to migrate the fix from the Version 2 tree into the Version 1 tree.

Promotion Modeling

Promotion modeling is equivalent to release branching, where each phase is a release. It is a development methodology in which source files go through stages. Source files might start in the development phase, be promoted to the test phase, and then go through integration testing, release candidate, and release. This phasing serves a couple of purposes. It allows parallel work in different phases, and it clearly identifies the status of all the sources. Separate branches are sometimes used for each phase of the development process.

Developer Isolation

A developer (or a group) needs to work on a new feature that will be destabilizing and take a long time to implement. In the meantime, the developer needs to be able to version his changes (check in intermediate progress, and so on). To accomplish this, he branches the code that he intends to work on and does all his work independently. Periodically, he can merge changes from the main branch to make sure that his changes don’t get too far out of sync with the work of other developers. When he is done, he can merge his changes back into the main branch.

Developer isolation also applies when semi-independent teams collaborate on a product. Each team wants to work with the latest version of its own source but wants to use an approved version of source from other teams. The teams can accomplish this in two ways. In the first way, the subscribing team “pulls” the snapshot that it wants into its configuration, and in the second way, the publishing team publishes the “approved” version for all the client teams to pick up automatically.

Label Branching

We label important points in time, such as every build that we produce. A partner team picks up and uses our published builds on a periodic basis, perhaps monthly. A couple of weeks after picking up a build, the team discovers a blocking bug. It needs a fix quickly but can’t afford the time to go through the approval process of picking up an entirely new build. The team needs the build it picked up before plus one fix. To do this, we create a branch of the source tree that contains all the appropriate file versions that are labeled with the selected build number. We can fix the bug in that branch directly and migrate the changes into the “main” branch, or we can migrate the existing fix (if it had been done) from the “main” branch into the new partner build branch.

Component Branching

We have a component that performs a function (for simplicity, let’s imagine it is a single file component). We discover that we need another component that does nearly the same thing but with some level of change. We don’t want to modify the code to perform both functions; rather, we want to use the code for the old component as the basis for creating the new component. We could just copy the code into another file and check it in, but among other things, the new copy loses all the history of what brought it to this point. The solution is to branch the file. That way, both files can be modified independently, both can preserve their history, and bug fixes can be migrated between them if necessary.

Partial Branching

Partial branching is equivalent to component branching, where the “component” is the versioned product. In this case, we work on a product that has a series of releases. We shipped the Everett release and are working on the Whidbey release. As a general rule, all artifacts that make up each version should be branched for the release (source, tools, specs, and so on). However, some versioned files aren’t release specific. For example, we have an emergency contact list that has the home phone numbers for team members. When we update the list, we don’t want to be bothered with having to merge the changes into each of the product version branches, yet the developers who are enlisted in each version branch want to be able to sync the file to their enlistment.

Identifying Branches (Configurations)

When a file is branched, it is as if a new file is created. We need a way to identify that new file. Historically, this has been done by including the version number of the file as part of the name of the file. In such a mechanism, the version number consists of a branch number and a revision number. A branch number is formed by taking the version number of the file to be branched, appending an integer, and then adding a second integer as a revision number. For example, 1.2 becomes 1.2.1.1 (where 1.2.1 is the branch number and 1 is the revision number).

 

Reference: The Build Master: Microsoft’s Software Configuration Management Best Practices

Tagged : / / / / /

Offline Checkout/Check-In in TFSC

by scmgalaxy KConcept & DefinitionLeave a Comment on Offline Checkout/Check-In in TFSC

  1. A contributor syncs his workspace and takes his laptop home for the evening.

  2. At home, he continues working and chooses to check out a file.

  3. An unmodified copy of the checked-out file is placed in the contributor’s cache on his local computer.

  4. The contributor continues to work and check out additional files. Unmodified copies of all these files are placed in the cache.

  5. When the feature is complete, the user attempts to check in the change set. Because the user is offline, the check-in option is not available.

  6. Wanting to begin work on the next feature, the user shelves his modifications for retrieval and check-in when he is able to go back online.

Tagged : / / /