We've already mentioned several times that software development is an iterative process (see importers). However, software development is also a collaborative effort. We strongly encourage group collaboration for lab specific instance development. Be it data importers or sparrow plugins, your lab will benefit greatly from a group effort.
Team workflows for software development are bit different compared to normal lab workflows. For one thing, everyone can have, at the same time, different versions of the codebase on their local computer based on what they're working on! This adds some complexity to effective teamwork; however, there are two industry standard tools created for software collaboration, Git and Github.
Git vs. Github
When first learning about these workflows people are often confused about the differences between Git and Github. In short, Git lives locally on your computer and Github lives online and is basically an online version of Git. Both are "version control systems" that allow you to track changes to the codebase and who made what changes. They allow you to isolate changes for certain bits of code and even merge two isolated changes to the same codebase.
Confused? Consider the following example:
Suppose I am making a pizza ordering and delivery app. In my first iteration I allow the customer to pick out what type of bread they want and which toppings. I release the app with this first iteration on a code branch that we'll call "main". A few weeks have passed and my app is doing well, but the pizza shop I made it for now says people can choose what type of base sauce they want on the pizza (marinara or BBQ). As the app developer I need to make some code changes to accomodate this new feature. I don't want to make changes to the main branch because while I'm making new changes I'm bound to create new errors and I don't want the app to crash. What I do instead is I make a branch off main and I call it sauce-feature. Now on the sauce-feature branch I add the ability to choose your own pizza sauce and once I'm satisified that the changes won't break the rest of my app, I merge it back into main.
This is the basics of a control version system.
Github is what will allow your team to work together and see eachother's changes to the code. We strongly recommend that every lab create a github repository for their instance of sparrow. In fact, without one it will be impossible for us to offer assistance in trouble shooting should you run into issues. Once you have a repository on github, each of your team members will be able to work on the same repository and contribute easily to the development system.
Git is the local version control system that lives on your computer. Through git you can easily interact with github by cloning repositories, making branches, and pushing local changes and local branches to the online repository for your teammates to see.
Sparrow collaborative workflows
Learning software development workflows can be a daunting task. It requires practice and iteration to find what works best. We at Sparrow still tweak our workflows to make them more effective. For example I'll outline a simple workflow that we use.
Sparrow has a
main branch that is the most stable release available. It's the version that comes with
the bundled version. Generally most of our development is done on a different branch
develop. While iterating on the
develop branch, we come across bugs or new features that we want to create.
When this occurs, we usually create a new branch of the code,
feature-branch. Once we are satisified with
our changes we push the
feature-branch to github and create what's called a Pull Request (PR) which is basically
just a request to merge the changes into
develop. While the PR is active, not yet merged, we can discuss the
changes on github, review eachother's code, and run tests to make sure the changes are stable enough to merge.
Once the checks have been done, the changes are merged, the PR is closed,
feature-branch is deleted and the cycle can repeat itself.