Social coding is the new wave in collaborative software development. While the word "social" would imply that it is applicable only to the open source world, its scope is actually much broader than that. Social coding brings the same benefits to the enterprise as it does to distributed open source development teams: enables your people writing better code faster.
Looking back in history, GitHub was the pioneer of social coding. GitHub focuses solely on the Git distributed version control system, but one must not forget that Git is not the only player in the Distributed Version Control area.
codeBeamer, Intland Software’s flagship product, is an Application Lifecycle Management (ALM) platform that helps distributed teams to manage their processes from requirements to release. It covers not only the programming aspect of software engineering, it provides solutions for information sharing, for writing collaborative documentation and for general project management.
codeBeamer is the only product on the market that provides social coding in a DVCS-agnostic way, by applying the same principles to both Git and Mercurial, the two most widely used Distributed Version Control systems. codeBeamer hides the differences between them, accelerating adoption and enabling mixed-DVCS teams.
Today, we are happy to annouce the general availability of codeBeamer version 5.7.
What are the most notable changes?
-
You can create any number of source code repositories per project.
You can even mix the version control types: you can have a project with two Git and one Subversion repositories. This enables smooth transition from the Centralized Version Control model to Distributed Version Control, gradually converting your projects and teams from Subversion to Git or from CVS to Mercurial, for instance. -
Integrator workflows: flexible, yet well-controlled method to review and integrate source code changes.
This is how it works in a nutshell: project members create their own forks (copies) of the reference source code and work on these forks. When they have completed a unit of work (implemented a feature or fixed a bug) and want to propagate their changes back to the reference code, they will ask the maintainers of the reference code (the so-called integrators) to merge a commit range from their repository to the reference one. They do it by sending a "pull request", which encapsulates what to merge and why to merge it. Integrators will then review and discuss the proposed changes, and decide whether to accept or reject them. It’s fast, efficient and secure.
You may be rightly asking: who will benefit from using the integrator workflow?
Simply put, everyone who has a supply chain for source code, or receives source code changes from an "untrusted source". Automotive companies, consumer electronic makers, mobile device makers, telecommunication companies, just to name a few. Don’t forget: (embedded) software is everywhere! More generally speaking, any company with junior employees, with contract workers, companies using outsourcing, or relying on external suppliers will secure their processes and increase their productivity adopting the integrator workflow. -
Inexpensive forking, easy merging with Git and Mercurial.
You can implement features on separate forks of the code, and merge them only when they reach a certain quality. Also, before codeBeamer 5.7 it has never been so easy to start a repository for experimental development, then drop it if it didn’t work out as expected. It ensures quality and consistency, improves project agility and fosters innovation.
Important links:
Intland Software is incredibly excited to shape the future of distributed software engineering. Over the coming months we will publish more details about our initiatives, including also EGit and MercurialEclipse, the two most advanced Eclipse plugins for distributed software development. To stay ahead your competition, read the Intland blog and follow @intland on Twitter.
