Lets talk about forks. They are so awesome for open source. Why?

• A fork is a natural way to give external contributors a place to work
• Really, that is the main reason to fork

Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:

• Developers need to maintain forks
• Additional setup to CI is required
• Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

If you hear someone talking about Gerrit, 99 times out of a 100 they will turn the discussion to their Jenkins setup (and oh boy, do I love speaking about Jenkins setups for different workflows!).

We are happy to release Jenkins Assembla Merge Request builder (or JAMRb for short) as an open source project to the Assembla and Jenkins communities.

JAMRb allows you to easily manage Jenkins’ jobs for all your merge requests:

• Set up template jobs (build, deploy, test) for your mainline and these jobs will be automatically created for any merge request in the project.
• Merge request got merged or ignored? JAMRb will clean up its jobs without the necessity to bother your Jenkins’ administrators.
• Want to build the future of your merge request before you merge, not just branches that they are based on? JAMRb will configure Build Parameters for target branch and use the remote of a merge request, so just before build you can verify if merge request applies without errors, otherwise fail build.
• Works fine with Assembla's Jenkins Auth plugin.

Just to give you a little taste of this, if your merge request view looks like this:

Jenkins before JAMRb:

Jenkins with JAMRb (extra jobs created automatically):

At the moment, this workflow only applies to git, however, merge requests for Subversion are already in beta. If you are using Assembla and SVN (or Perforce) and are interested in this setup, let us know in the comments.

The FTP tool will automatically deploy code from your code repository to any server with ftp or sftp installed.  This is a useful way to deploy Web sites and PHP code.  Watch the following video to learn more about this simple tool.

Some key points to note before you watch the video below:

• Add the FTP tool using the Tools section of your Admin tab.
• Deploy code to any server with ftp or sftp installed.
• Set the deploy frequency to manual (you push a button) or schedule automatic deployments for every commit, hourly, daily, or weekly.
• Only changed files are deployed for fast and accurate deployments.
• Easily roll back and deploy prior revisions.
• Add multiple servers for staging and production releases or simply to deploy different repository directories to different locations.

Watch how easy it is to install, configure, and use the FTP tool:
 

Have a more complicated build process? The Build tool can assist you in running continuous integration. Using simple Web services to trigger builds with Capistrano, Cruise Control, and other build systems, you can automatically trigger new builds with the same fine-grained control you get when you use our FTP Tool.

Introduction

Setting up Git can be intimidating, especially for those that are trying a version control system for the first time or moving from Subversion. It used to be the case that Git was a huge hassle to install and use on Windows. However, nowadays it's super easy to use Git on Windows either through Git Bash, if you're a fan of the command line, or if you prefer a graphical interface, through programs like TortoiseGit. Below we'll show you how to set everything up and connect it with Assembla.

Table of Contents

1. Download and Install Git for Windows
2. Download and Install TortoiseGit (Optional but recommended for first timers)
3. Generate SSH keys
4. Link SSH key with Assembla

Prerequisites

1. Assembla Git repository - sign up if you haven't already, it's totally free for standalone Git hosting.
2. A strong desire to install Git on Windows.
3. That's it, let's go!

1. Download and Install Git for Windows

To get things started, you'll need to download and install Git for Windows. You can download it here. If you're unsure of which one to choose, just go with the full installer. After downloading, run the installer.

 
If you have PuTTY/TortoiseSVN installed, you may see this screen, otherwise just ignore this. Regardless, use OpenSSH to make things easy. 
 

Download and Install TortoiseGit

This step is optional. If you are comfortable using the command line for interacting with Git, you do not need to install TortoiseGit.

Next up, let's download and install TortoiseGit.
 

We'll need to configure TortoiseGit - to do this, right click anywhere on your Desktop, select "TortoiseGit" and then "Settings."


Find "Git" and then click on "Config" from the menu on the left. Then fill in your Name and Email, making sure to use the same email that you used to sign up for Assembla.

Don't forget to click OK when you're done.
 


Great, now TortoiseGit is all set!

Generate SSH keys

There's two ways to generate SSH keys:
  1. If you installed TortoiseGit, use the method directly below. 2. If you only installed Git on Windows and are not using TortiseGit, jump to the "Git Bash SSH Keys" section.

TortoiseGit SSH Keys

SSH creates a secure connection from your computer to Assembla, making sure that you are who you claim to be so that only authorized persons can commit to your repository. Assembla needs to know your public SSH key to make the secure connection, so let's fire up Puttygen to generate an SSH key pair.

Start -> Programs -> TortoiseGit -> Puttygen


In Puttygen, first click on the "Generate" button.


Next, you'll move your mouse around the big gray area under the progress bar to generate randomness for super security.


Once the key is generated, you should copy it onto your clipboard. You'll use this later to authenticate with Assembla.


Afterwards, choose a memorable password and confirm it. Don't forget your password!


Lastly, click on the "Save private key" button and save your private key somewhere you'll remember.

Git Bash SSH Keys

If you did not install TortoiseGit, you're at the right place! If you did install TortoiseGit, follow the steps above and skip this section.

• Start up Git Bash: Start -> All Programs -> Git -> Git Bash
• On the command prompt, type in the following command substituting with the email you used to sign up for Assembla.
• When it asks you for the file, just hit Enter.
• Please note that you should definitely enter a passphrase; when you type, nothing will show up. This is normal, don't worry about it.

ssh-keygen -t rsa -C "me@email.com"

Use Notepad to open up the .ssh/id_rsa.pub file you just generated and copy the all of the contents of that file.

Link Your SSH key with Assembla

Open up your Assembla profile which is where you'll paste the public key you just copied from the previous step. 
 

Assembla Subversion and Git users are now able to access both affected files AND tickets when comparing what has changed between revisions. This update makes it easier for release managers to know what tickets were affected in a revision or between a range of revisions.

The "What changed" feature shows files that were changed between two revisions.

In order to track affected tickets, you must reference tickets in commit comments. For example, “re #1231” in your commit comment shows that your commit is related to ticket number 1231. Or “test #1231” shows that your commit is in reference to ticket number 1231 and will also update the status to test.

Using "What Changed"

In your Subversion or Git repository, go to the Changesets sub tab, click the “What changed” button, and in the pop up, enter the two revisions you want to see changes between. The AJAX search will find what you are looking for as you begin to type. Click compare. 
 

Scroll to the bottom of the page and you will have two tabs – Affected Files and Affected Tickets. Click on the Affected Tickets tab and you can see the summary, milestone, assigned to, and status of all affected tickets between the two revisions. From this tab, you can also update or access these tickets.
 

Assembla has always offered git repositories using the ssh and git protocol, but some corporate firewalls block these protocols. In our latest server upgrade last month, we implemented git over HTTP which will allow the use of git behind most corporate proxy firewalls.

Use git over HTTP with the following command and URL:

git <command> https://<username>@git.assembla.com/<spacename>.git

You must have git 1.7 or higher, with the git-http-backend.

Git over HTTP received a lot of votes on our feedback site, and we are happy to have provided this update for those stuck behind corporate firewalls.

Here are some of the new features in today's release.

New Top Bar Navigation

We added a top bar for navigation and eliminated extra tabs from the user/start page. The top bar makes it easier to access your start page, go to spaces, and edit your account. When you log in, you will see the following screen:

1. A "My Start" link on the left side takes you to your start page from anywhere in Assembla. 
2. Your first three workspaces will be listed on the top bar for easy access. To show your most frequently visited workspaces, go to your start page and drag the circles for those workspaces to the top of the list. 
3. A dropdown menu is located on the right side, under your name and picture. From this menu, you can access the edit profile page, view your account information, and log out.
   

 

Multiple Languages (Beta)

To serve Assembla users in over 100 countries, we have begun translating our tools into multiple languages, starting with Spanish and Russian. This release is a beta test that only includes select tools such as Tickets, Milestones, Support, and Subversion. In following releases, other Assembla tools will have been translated into Spanish and Russian, and we will begin adding support for additional languages. To update your language preference, go to the Edit Profile page and change the dropdown for Language Preference (see image on right).

Messages Tool Improvements

We simplified the Message tool.  The Messages tool should be a place where any team member can easily post a messages without starting a new email thread.  This makes information accessible to more team members. The revised tool does not have nested threads, which were confusing to navigate.  It has one "conversation" for each top-level topic. The new tool also has simplified forms for posting messages and comments, and fewer controls.

More Estimates

You can turn on Estimates in Ticket settings.  If you do, you will see estimate totals on Milestones, and you will see estimates on cards in the cardwall.  Now we have a popup editor on the agile planner.

Git Merge Requests

We upgraded git merge requests to better support the classic git workflow where developers submit merge requests to a maintainer.  We will improve this in future releases with better review workflow, including some features that we like from Gerrit.

To send a merge request, select a branch, tag, or revision as the source.  Select a branch as the target.  You can review changesets and write comments.

 

When you receive a merge request, and you want it, you can use the instructions to apply it.

I have never been a fan of pair programming. Two grown men huddled over one keyboard are sort of like girls who go to the bathroom in pairs. What are they doing in there? They don't share a stall. That would be too slow. If your programmers are good, gossiping in pairs just takes away the bursts of individual intensity that great coders deliver.

Plus, our developers are in different places, which is the reality of modern work.

So, how did we end up working in pairs on the current Assembla release?

It started when we decided to try Gerrit code review as a way of scaling our team. Realistically, people aren't going to do code review unless you force them. Gerrit is particularly rigid. Your code doesn't go in until it gets two votes.

This created some serious bottlenecks. At one point the list of "changes" for review held more than 26 changes that had been rejected, with big nasty red X marks on them, and one with a happy green upvote. On a healthy list, there would be fewer waiting, and a lot more green.

We diagnosed a couple of problems.

• Reviewers were being over-enthusiastic about enforcing minor points of style. They were rejecting almost everything. Why not just fix these cases? We needed to reorient them to fix a problem if it was small and they knew how to fix it.
• Developers were in multiple time zones, and it was taking a long time to get reviews, and a long time to respond to them.

We though we could fix both of these problems with pairs, and it worked. Our pairs don't actually watch the same screen or share the same bathroom stall. The pair is simply an arrangement to review each other's code, and to discuss it. When you work with a partner:

• You work on the same basic feature, and you both understand it.
• You make it a first priority to review committed code.
• You fix your partner's code if you can.

This lightweight pairing really works in our distributed team.  I think that enforcing code review is the thing that makes it work.  Pairing, actually, is not important.  You can have three or even four people in a review group.

We got a knowledge sharing benefit. Bosses often support pair programming as a way to train new people, share knowledge, and make sure there are no problems if a key developer is not available. Our pair partners are getting trained up on many specialized parts of the system.

We got a productivity benefit. Reviews and pair communication take time. They make the team slower. I'm not convinced that pairing and reviews magically reduce total time because of added quality. Extra work is extra work. However, I have noticed that the team is moving faster, and I think I know why. They are working more. Shhh... don't tell them I noticed. They are working more because they like working with pair partners, and being able to talk about their work.

 

Code review was an experiment to set us up to bring in more people, and enforce some uniformity in code quality, style, and tests. There are various ways to do code review. Most simply, you can make it a policy that changesets get reviewed and commented with our upcoming simple code commenting feature. I'll post on that next week.

We support a number of coding repositories and workflows on Assembla. This article is a high-level overview of the alternatives.  Some material about code contribution comes from a previous article Agile next generation: Three ways to go beyond scrum.

Innovation in development relies on changes in the way developers deliver code, which is closely tied to the evolution of code repositories. There are many code management workflows, but most fit into four categories.

Lock: Years ago, developers used to copy a part of the code base to work on, and formally or informally lock it, so that other developers wouldn't work on that part.  Assembla subversion still has “lock” operations to support this.

Merge: The next development was merging.  Developers could work in parallel on the code, and they could "commit" code whenever it was ready, but if they were committing a file that someone else had also changed, they needed to merge.  The next generation of version control systems had better support for this merge process, and largely ignored locking.  This commit and merge process enabled faster development because you weren't always waiting for someone else to finish.

However, it created a new problem.  If you have enough developers making enough commits, they tend to commit errors or conflicts, and you get broken builds.  So, you limit the number of people who can commit, creating a new scaling bottleneck.

A central repository with merging makes it pretty clear what is happening in the team, and makes it relatively easy for everyone to work on the same thing.

All of Assembla's repositories - Subversion, git, and mercurial - help individual users update and merge code while working in parallel.  They also support state of the art notifications and code viewing so that you can track what other people are doing.

Pull: Distributed version control systems like git provide a safe place for developers to commit, merge, and test in their own repositories or branches.  A technical lead or "maintainer" can then pull the changes, test them, and commit them to a master branch.  This pull process allows any developer to work on a new version.  It expands the pool of potential contributors and the effectiveness of open source development.  However, it depends on the capacity of the maintainer to pull and test code.

Assembla git and hg support this process with branch and "fork" operations to create contributor repositories, and patch requests to bring code back into the master version.

As illustrated in this diagram, there is a lot of pulling and merging required in this process.  Each contributor is essentially a maintainer for his own repository or branch.  In exchange for this work, you escape the curse of central planning, which is that the central planner is not omniscient, and doesn't know what to do, or creates delays.  Just do it!

Review and Accept:  If you use a scalable process for reviewing and accepting code, the maintainer will not be a bottleneck.  When developers post a changeset, it will go through automated tests, and gather votes from code reviewers. If it passes all tests and gets enough votes, it gets accepted and merged into the master branch.  This process is scalable because you can have many people that are authorized to vote and and approve code.  With Assembla's Gerrit release, we support this process.

The Gerrit process runs off one central code version, and requires less work from each contributor.  This "trunk oriented" workflow builds teamwork by making sure that everyone is working on almost the same thing.  We use it, and so does Google.

Assembla customers like how easy it is to give customers visibility into the development process. But why is this important?  Why should companies want to engage customers in the development process?

We heard some answers to this question in a recent conversation with Rob Heittman, CTO of Solertium.  Solertium has built up a competitive edge around close engagement with customers, agile processes that deliver software that meets real customer needs, and Assembla workspaces.

Solertium wrote the software that lets you order lunch on your Android device from Five Guys Burgers and Fries, and vote on the best frequent flyer program at the Frequent Traveler Awards web site.

The company is best known for creating conservation applications for global non-governmental organizations (NGOs). These include the Red List of Threatened Species™ for the International Union for the Conservation of Nature (IUCN), and the Project Planet Ocean Portal for the IUCN and Google.

So how does customer participation in the development process help with these goals?

1) Engaged customers gain confidence that the development team is getting work done and staying on schedule.

2) Customers can give feedback promptly and really fill the role of “product owners” (versus having developers try to play stand-in and interpret customer requirements from a distance).

3) Customers update themselves, instead of sucking up the time of team leaders with status reports.

According to Rob: “customers get a sense of velocity and activity” by viewing emails, activity streams, tickets and milestones.

Further: “they can jump in and give immediate feedback if we didn’t exactly understand their requirements.”

Also: “I save a lot of time because I don’t need to schedule endless status reviews or spend hours writing status emails.”

Rob warned that transparency is not for everyone: “it makes you more accountable.”

But if you can handle the transparency, he said, “your customers will be much more loyal, and much happier because they will get software that really meets their requirements.”

Solertium is also a technology leader.  They use Gerrit to accept and review contributions from their global development team.  Rob tried Assembla's Gerrit release and noted "I can see immediately one killer advantage of the Assembla Gerrit solution: code review activity appears in the Stream. We use the Stream to get a visceral feel for velocities across projects, and sometimes there is lots of activity going on in code review that was largely invisible. There are also cases where, if a contributor knew there was activity in code review, they would weigh in on it. The Stream integration allows that kind of spotting. Great stuff!"