Software Development Tools

Interlated is our software development arm. The tools, processes and required mindset are different to a project whose aimed at well targeting publishing rather than application development. 

However, MountainRiver CMS often works with people who do development and to smooth the process along here are some of the challenges and tools that we use. 

Specification

With agile software development specification of smaller increments before you build them is highly important. 

• User stories. There is an art to writing them. I refer to Cohn - User Stories applied. We use 'icescrum' to manage stories.

Tracking

I prefer to 'not have too many systems'. Ideally bugs found during the software development process result in the story being rejected and circulated through a second development phase. If it is new functionality we create a new story that goes back to the planning and estimation phases. It is possible to have a story tracking system plus:

• A bug tracking system. Jira works as a software as a service system although we have effectively used mantis and bugzilla. Bugs can be different to stories or 'urgent tasks' in that they impair the current use of the system and should be fixed as a priority. Caution though, if you have more than one list people will focus on one or the other. 
• Customer issues system. This is where people raise problems. Great for 'contact us' on the website if you have a big user group for your website. However, be aware of the 'multiple lists' problem and if the customer side of your web development team is engaging with this rather than the scrum tool they are probably not working to understand their project. User stories are a communication tool and as such if the customer doesn't understand them, then more coaching or practicing of the principles of Domain Driven Design is needed. 

There are other systems such as configuration management systems, project tracking systems, mailing list systems or just notice boards such as basecamp.

Version Management

Version management is the core technology of any software development project. Git is the tool that we use. Git is a highly flexible tool which works in a fully distributed way that enables a number of development processes. Branching is cheap and solves a number of problems.

Prevents partial releases of software further up the chain. Particularly: 

• Separation of working software from software under development. This allows fixes to be made to production software if needed while not deploying software under development. 
• Testing cycles. Testing can be managed on a relatively static copy of the software. Bugs can be fixed without new features introduced that require a restart of testing.
• Allows multiple developers to work on different components in relative isolation​. 
• Enables user-acceptance-testing (UAT), quality-assurance-testing (QAT), live deployment models. As 'git is distributed' each of these systems can be tracking a branch and pull or push software as needed. 

Branches also allow software to be labeled and builds reproduced at a later date. Git has a flexible suite of tools - tags, date references and commit references that can be used to reproduce any development point.

The 'git is distributed' feature allows people to: 

• Not push to deployment systems until they are sure it works. 
• Not push to testers until the software is ready.
• Not push to other developers until they have a working copy. 

However our experience shows that, people will accidently push and you need to share your code so that others know what you are doing. If you can't share because this is your staging model it can be a problem. The 'just a quick fix' on the production branch that gets half finished and forgotten about, always gets pushed live. This approach usually doesn't work.

Don't forget to pull/fetch always and often.

Branching Models

Our preferred branching model is a release/feature branch system. This involves building features until they are ready and then pushing them onto a release branch. For example I am building a 'performance calculator' component of a website. I use the feature/performance_calculator branch until I have finished developing it. I then push it onto 1.3 which is the branch that is currently undergoing testing. 1.2 being the currently deployed branch.

A graphic of this process.

The alternative approach is not to use branching - just work on master - or use a cut down number of branches to avoid branching. Do this if: 

• your software is going to only take 2 weeks to develop. 
• there is only ever going to be 1 release. 

It happens, but it is rare and quickly you will find that development changes are affecting testing and one release is leaking into another. 

The justification for this is typically that there is additional friction in creating branches - people not sure what to work on and challenges in merging. These problems are largely dealt with by graphical repository browsers and IDE's. 

Problem: I was working on 1.1 branch, had a break and people moved onto 1.2. The main tool I use for this is GitX. It can show all the branches at once (same as git log --all on the command line but people don't do this by default). GitX also lets you use the arrow keys to page between commits and quickly see what files have changed and what the changes are. 

MountainRiverCMS/Interlated also run gitblit, which I mainly use for repository discovery.

MountainRiver CMS provides our own Git hosting service. Git is integral to the way we work and we can manage it although there are a range of such providers such as github, bitbucket and unfuddle.

Editors and Integrated Development Environments (IDEs)

Not so long ago (maybe a decade) developers saw IDEs as a crutch for those that didn't know what they were doing and as bloated/productivity killing wait devices. Real developers used vi. Now IDE's those 15 CPU cores that would be doing nothing are running, watching a software developers back. There are 2 things that I use IDE's for: 

• Syntax checking, lint checking and background validation. In the past we edited code, and ran the compiler a few times to find all the typos. "Missing brace line 768" was an art to find quickly. Now the IDE will show that it is missing and where it is, practically while you are typing it. Don't send me html code that doesn't pass W3C syntax checks, missing brackets, duplicate id's. The IDE should find these and alert you to them in the first instance.
• Debugging. Printing variable output to the console. No. The tools now let you step up a call chain and step back. To find out where things are set, you don't even need to rerun the test.

The IDE is also useful or history browsing. Intellij keeps a copy of every change, so just delete code that isn't currently working. If you want it back, browse version management history and a convenient merge tool lets you copy it back in.

History browsing, merging and code navigation. It is very difficult to merge text without a visual editor. Intellij stands out here.

Version management - it is more convenient to pick files for commits using the IDE than command line, although people do have their ways.

The two tools I would recommend for java/php coding are Intellij and Netbeans. Intellij (phpStorm) has a cost and Netbeans isn't quite as good (slower, not as sharp on code analysis but better database tools).

Testing

Automated testing allows tests to be rapidly re-run and provides a greater assurance that software produced at each stage is functional and matching quality standards.

Integration Testing

Integration and Unit testing are highly important in software development projects as they ensure that software is working in a particular way. If just building a website then quality assurance testing and  interface level functionality may be more important to focus on. 

The development environment, such as grails is likely to provide a testing framework. If it doesn't this is a big minus.

I like to use integration testing as far as possible, it is slower but mock tests are sometimes not convincing.

Functional Testing

I use Selenium and Geb.

Benefits: 

• Rerun tests without typing into browsers so much. 
• Being able to reproduce a test and send it to someone in order to communicate the problem.
• 'Lights out' end to end testing. 
• Automatically capture screen grabs for reporting.

Disadvantages: 

• Functional tests change every time the interface changes. This can mean that the tests won't work when you leave a project and come back to it. This is when you want the tests to work so that you can remember what it was supposed to do.

Quality Assurance Testing

Do use the W3C validator. 

Use the W3C accessibility checker, although note the limits of automated accessibility testing and make sure that the accessibility processes match the goals of the project.

Cross Browser Testing

Cross Browser testing. This is labour intensive and we still use virtual machines to analyse problems cross browser. Netrender (and equivalents) does allow for some online analysis - if you are doing a lot of this software as a service products may be worth your money as it doesn't always work. Firefox has cross browser rendering tools, but they aren't very trustworthy. 

Staged Environments 

We use git to manage UAT, QAT and live deployments. Your project will need these, one for each testing group so that they have a stable target to test against.