We use Git everywhere in our company, from source code to our homepage & blog. Its distributed nature makes it perfect for teamwork. We highly appreciate how Git encourages frequent branching/merging, tagging of releases & the pull mechanism that makes code reviews much easier to handle. To minimize management & ops, we are using Github for all our Git work.
All our projects use automated build systems. For Java projects, we build with Maven, while for Scala we use SBT. For all frontend apps, we have a combination of Grunt, Bower and NodeJs. All our projects share a common build pattern, so once you’ve built one, you know them all. Any build is triggered with a single command line.
We are using Jenkins on a really fast dedicated build server. Any commit to a Git repo triggers the build job that pulls the latest changes, builds them, runs the tests, restarts the dev instance & publishes the artifact in a private Archiva snapshot repository. So, we have commit level builds. Even better than daily builds.
We have a dedicated machine that runs a heavily customized Redmine where we keep track of stories, features and bugs. We integrated the issue tracker with the Git repo, so we also keep track of code commits per issue. All issues we track are further grouped by project, component and version/release.
In most cases, bugs get a high priority and as such, they tend to get fixed before new features are added. We have a pragmatic approach regarding this rule, as there are some cases when bugs are minor and some new features might end up being more important.
We track business functionality as stories and connect the implementation issues with these stories. This approach allows project owners to easily track implementation progress and schedule deadlines at a story level. The development teams commit to specific stories every 2 week sprints.
We start projects with data model specs and architecture documentation. We use UML diagrams for data model specs and the architecture documents cover the top level components, persistence layout & technology stack. All our API’s are RESTful & are documented at the HTTP request/response level semantics.
Our office is located in a quiet old building near the city center. We lower the noise level by keeping phones or Skype conversations outside the work area. We always use headphones for music.
We all have laptops with very fast CPU’s, SSD’s and as much RAM as you can get. Everyone has at least one secondary monitor. For automated builds & tests, we have dedicated high end servers. We also have a big screen that shows build statuses for all projects in real time.
We have automated tests both for backend and frontend, as well as dedicated testers.
We require candidates to code during the interview process. It’s also a big plus if candidates contribute to open source. We encourage & appreciate visibility to meetups and tech conferences.
The closest we got to it was by using TestFlight to distribute development releases to remote testers. It’s a good starting point and we are looking on ways to improve this part of our work.