Web development in a small team - best practices

Question

Currently developing a web app in a team of two maybe three in the near future. Tech stack is at the moment : flask, mongodb, and extjs for the fontend. I currently have the project under version control using mercurial and bitbucket.

Question

What is exactly the best way to work as a team on a we app peoject? I ussually work on the back end while my colegue works on the frontent. Sometimes i also help out on the front end. How should we do this? Each has a repo on their system but whee is the web server started? Curentlly i have it on my computer but that means that my partner needs to commit and push for each modification and i need to pull the changes and merge for each change. And for frontend stuff there needs to be a lot of changes. We tried having a server started on each of our machines but its a pain with multiple mongodb servers.

Anyway any tips, clues and advices are greatly appreciated and welcomed.

Answer 1

I've worked in multiple projects in a similar environment to what you describe. In my experience something like this works pretty well:

• Each developer should have their own development setup - servers, databases, etc.
  • You need to be able to test your work quickly and without disturbing other people's work
• You also should have a "testing" or "staging" server.
  • This is where you should try to keep an environment as close to your production system as possible.
  • You should test your code here before moving code into production
• The source control repository can be kept on a server as well. (This could be your staging server too, you don't necessarily need a separate one)
  • Although mercurial keeps copies of the repos on the dev machines, it's easier to keep everyone updated if everyone pushes their changes to a central repository.
  • You can also do deployments to staging/testing and later production more easily if all the code is in a central location.

To address some of your problems...

At least with SQL databases it's relatively simple to keep the database shared. You can just take dumps of the data and copy it over to the other people.

You don't necessarily need to have the same exact data on all developer's computers. It should be enough they can perform testing etc. with the data they do have.

The testing/staging server should preferably have the same data as your production server - this is to ensure your code gets tested in a realistic environment before it's moved to production.

Answer 2

There are excellent tools to allow collaboration from small to big teams, what tools you choose depend on the size of the team, size of the project, ...

One goal is to have constant communication with your team. For that I recommend:

• Stay connected, use IRC (and log it)! Use skype/video/gmail or whatever for 1 to 1 communication, but for teams IRC allows a kind of communication that others somehow don't fulfill. You should be on IRC anyways if you are developer, and you can integrate other tools to send notification to your channel (commits, tests)

• Use a bugtracking system, plenty of which to choose from.

• Use any kind of project management system, tools like redmine, agilezen.com, or an excel sheet. take your pick.

Another goal is for all the developers to have the exact same development environment and kind of data, in a reproducible and automated way. For this you can you a combination of tools:

• vagrant + provisioner (provy,chef,puppet) + fabric
• use fixtures, mock data apps, random fixture generators for your data, and mock 3rd party services in way that you can reproduce and depend on.

The use of virtualmachines provisioned programatically also allows you to develop very closely to your deployment environment, without having all your team members having to install and configure them locally, without losing the flexibility and without the headaches that sharing resources can bring (specially if the team is geographically apart).

Another goal is that team members don't step on each other's toes. Not only not breaking your colleagues code, but also includes avoiding duplicate efforts. Some things you can use:

• use a DVCS with a centralized server (i.e. bitbucket) with a coherent commit workflow that also includes deployment. "i.e. git-flow like workflows or always deploy trunk workflows"

• setup a Continuos Integration server (jenkins or teamcity i.e.) and write tests like crazy. Track your code coverage and commit to keeping your code with the highest coverage you can. Use unittests, but also use browser testing, i.e. selenium (i like using selenium for more general storylike tests, and unittests for more low level operations, and selenium allows you to test the interactions of the backend and frontend code)

• commit contract: Have your team use branches for development, and commit code to the main branch when all the tests pass.

• automate your deployment, setup a staging server (that can/should be provisioned with the same scripts as your vagrant box) and hook up your CI server to deploy to it at least once a day when all tests are green from the main branch. After automated deployment, run tests against the server, including load tests, (i.e. with funkload, or selenium, etc..) and graph it using graphite!

• Use a bugtracking system. Its a waste of time if two on your team are tracking down the same bug and trying to fix it at the same time without knowing.

You don't have to setup everything from the start, and you might not need to use all the tools. Just keep on eye on those moments where you start to need them.