tools Archives - The Software Blog

What tools are required for teams that are developing software for the cloud? Verify this checklist to find out if your team has the basics for productive software development in place.

Contents

Versioning system

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need a versioning system read here)

Each team member is able to revert source code to a former version at any time.
You are 100% sure that this works because you have tried and tested it
You are able to quickly find out what has changed between versions
You are treating configuration files, documentation and any other artifacts like your source code – everything is under version control
Team members check in modified source code at a regular basis
Your team has agreed on a common branching strategy
If your versioning system would fail completely today there would be no panic. You would just set it up again from scratch and reload yesterdays backup. You know that this would work because you have tested it at least once.
If yesterdays backup was not created there is a notification in your team mailbox

Issue tracking

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need an issue tracking system read here)

The team has a complete list of all currently known bugs and issues
The list is accessible to each team member and everybody is be able to work on issues (e.g. add comments)
Each team member can see “his/her” issues with one single click, and ideally get automatically notified about status changes for “his/her” issues
The team has a clear policy on issue status management: what issue status values exist and who is allowed to change issue states? An example: many teams follow the principle that an issue should be verified and closed by the person who initially opened it. Your team may want to handle that differently – just ensure that everybody agrees on the same standard.
Each issue in the list has at least:
- a clear title and a description that each team member can understand without need to ask whoever has written the issue
- a status and an owner within the team
- additional information required to tackle the issue (screenshots, steps to reproduce, logs etc.) and meta information that helps to manage the issue and understand its history (time created, component or service concerned, version, …)
Daily backups are created and stored on a separate system. The backup / restore procedure has been tested at least once. This is not required if you use the cloud service of some provider (see article)

Build and Deployment System

You know that you
(1) have one, (2) it is set up correctly and (3) and your team is using it
… if you can answer the following questions with YES (in case you’re not sure if you need a build / deployment system read here)

Each developer can create a new build with a single command or click
Build status is visualized and team members get notified about build problems
New builds can be deployed to the desired environment with a single command or click (at least for the productive environment most teams will set up rules regarding who and when this is is allowed)
You can always tell which version is installed on what environment
You have a track record of builds and deployments

Team Collaboration and Knowledge Base

You know that you have what you need if you can answer the following questions with YES (in case you’re not sure if you need tooling for team collaboration read here)

Each team member can access a common system and find the most relevant 5 documents via direct short link
Each team member can add or modify content
Each team member can search for information or documents via keywords

Check out these related articles:

What tools are essential for agile development? A code editor may be enough to get started. But what are the must-haves for every dev team?

(1) Software versioning

Never develop software without a versioning system. Why? sooner or later you will need to know what you changed since that last version that actually worked and did not have that strange bug you have now been tracking down for hours. Or you may need to fix a minor problem in the productive version but don’t want to roll out all your latest untested changes. Or you work in a team and several people contribute to a common product or service.

A version control system is a central code repository and provides what you need to combine work results in a controlled way. Don’t try to get along by copying your sources around in different folders or zip archives. There a many great tools for proper version management, pick one and use it. GitHub is one of the favorites. it even takes care of permanently and securely storing your sources. Left your notebook in the coffee shop and now it’s gone forever? Well bad luck, but at least you still have your source code available. And while we’re at it: put everything under version control, not only your source code. Version control your configuration files, your specs, your user documentation – whatever you and your team are producing. It’s just like a car insurance – sooner or later you will be grateful for having it.

(2) Issue tracking

Software comes with bugs, and you need a system to keep track of them. You’ll want to know what problems have been found in which version of your software, what has been fixed already. Team members will need to add comments, logs or screenshots to an incident. Ideally you may want to link the issue to the code in your central repository that fixes a the problem. And since you work in a team you want a system that supports simultaneous multi user access. Don’t waste your time trying to do all this with some spreadsheet software. Yes you could do that, but it won’t really work. There are many good incident management and bug tracking systems available. You may want to take a look at the issue tracking that comes along with GitHub, or check out Jira – these are probably the most popular ones.

(3) Build and deployment automation

Software is born on one or several developer machines, but this is (hopefully) not where it is going to be run for productive use. Various steps need to happen before the checked-in code arrives in production. Depending on your development environment, programming language, used components etc. the artifacts for the prod system need to be built and versioned. You may want to apply static code analysis. Deployment to a test environment comes next. If all tests have been passed you or product management or whoever is responsible for that may decide to put that shiny new version out for productive use by your customers or users.

Let’s note that most of these steps need to be automated in order to get to reproducible high quality results. The system behind this is often called the build pipeline because things happen sequentially in a predefined order. If any of the steps fails the pipeline stops – the team needs to fix the problem and restart the pipeline again. A basic build pipeline system is e.g. available as part of GitHub. Then there are many open source and commercial solutions out in the market, and each of the major cloud providers offers a solution. If you’re not sure what to use start with GitHub – you can always move to some other system later on. Just make sure that you have an automated build and deployment approach right from the beginning. Improve it over time.

(4) Team collaboration

This is a crucial topic and the perfect approach for team collaboration yet needs to be uncovered. And of course no tooling will ever replace person-to-person communication, willingness to engage, to share information, to work together. Check out this [] blog post to dive into this. Having said all that – collaboration is still an area where good tooling really can make a huge difference. What you want to have is a central place for all your team’s information sharing needs. Documents, drawings, ideas, team calendars, whatever. You will want to search for stuff, and create links between various pieces of information.

Of course you could just store stuff on some shared folder or Dropbox. However this will be far from good. Who will want to browse around in some obscure folder structure? Admit it – this does not even work for your own stuff on your notebook, am I right ? We are in the new millennium and Wiki’s have been invented – if you’re not using one already please start to do so now. Once you have used one you’ll wonder how a team could ever have survived without. It will of course only be accessible by your team, and each member can set up new pages and content with a few clicks. Documents become much more lightweight and can easily be interlinked. Updates are done in seconds and you’ll have one valid version per document only. Paradise. Who knows, maybe even your most no-documentation-required style people will start to add stuff to existing pages.

There are many hosted Wiki flavors out there, setting one up for your team is a matter of minutes. A good choice is Confluence (by Atlassian – no I’m not getting paid by them, I just like their software). If you happen to use their Jira for issue tracking you can take advantage of the integration between both. In my opinion a great choice and all you need to cover your team’s basic tooling needs.

(5) Is there point 5 ?

Well there’s many more tools out there for life-cycle management, test automation, code analysis, etc. etc. – but these may be somewhat more advanced topics and your needs will depend on the type of software you develop, on your programming languages, target system and so on. For now we wanted to stay with the indispensable basics. You can always add to your tool-set, just make sure you’re not missing out on versioning, build automation, issue tracking and a Wiki – the basic tools for efficient agile development.