There are a wide variety of task recording, documentation creation, team communication and deployment systems out there. In the second instalment of this article, we shall see how these tools can be turned into an efficient system. By connecting these otherwise independently functioning tools together, you can reap substantial benefits.

Also, you should not miss the previous part of the article series about web integration – Putting Continuous Integration (CI) into Practice – Part 1. It is a must-read!

A project management and issue tracking system

Whether you have a completely new project or a post-sale application, an issue logging and tracking system is a must. Before your developers start cutting code, you need to define the tasks to which you will assign particular programmers, that is, tasks the progress and cost of which can be monitored against targets.

At Krcmic.com and Onlineandweb.com, we used Mantis Bug Tracker in the past, which, however, does not meet the requirements of today’s software project management. It is a good, albeit a little cumbersome issue logging system, but it lacks certain core features that are absolutely necessary for us today.

Modern application development is unthinkable without a flexible bug management system that actively supports the implementation of agile development management methods. We currently use the JIRA issue tracking system which has the following advantages over Mantis:

• customisable project workflows;
• combines the features of an issue tracker and time tracker;
• supports team work (a user access and role management system)
• can be easily configured to interact with other tools (Bitbucket.org, HipChat IM, Confluence);
• is user-friendly.

Like other Atlassian products, JIRA is not cheap, but we currently use it as a replacement for two systems (issue tracking and time reporting). JIRA is easier and faster to work with and as such, directly saves us time. Moreover, we have custom-developed one of the systems, so we will be able to save considerable development, servicing and bugfixing costs in the future.

We recommend connecting the JIRA system to a central source code repository (see below), making it possible to drill down for details on the work that has been done and its authors. In addition to the verbal comments left by team members, we have access to the related technical details of the implementations.

Workflow

The choice and use of a suitable workflow are very important considerations. JIRA offers some out-of-the-box workflows that are available as part of the installation, but these do not exactly fit the processes within software development.

The workflows in JIRA are fully customisable, which can be both a blessing and a curse. This freedom may be a certain advantage, but you are faced with the necessity of capturing recurrent situations and processes common to most projects. Creating workflows that are usable for more projects necessarily involves some compromises. The deeper you dig into the configuration options, the more likely you are to accommodate specific requirements and create special-purpose workflows. This has more disadvantages than it has advantages. A smaller number of workflows aid in orientation; the statuses (To do, Done, Accepted…) and other properties ought to be unified across projects, which helps avoid misunderstandings in communication and in managing the processes themselves. Both managers and developers have an easier time of navigating a limited number of universal workflows, rather than having to choose from dozens of specialised workflows. For this reason, we have adopted the use of workflow schema definitions, which can be carefully prepared for the company and which users can choose from when setting up new projects.

User-friendliness may not be the primary consideration, nevertheless, a good GUI saves time and motivates employees to use the system with respect, if not with pleasure. On-site editing, search, autocomplete and keyboard shortcuts are just fantastic features!

Time reporting

We used to have a time reporting system that was set up independently of the issue tracking system. It was a custom-built system that we created ourselves. However, we could not continue developing it forever and to upgrade it to meet our evolving needs would have meant virtually creating a new application.

What are the benefits of merging the two systems into one?

• directly related information on bug logging and the progress of bug resolution is stored in a single system;
• less time is spent on logging work, reporting and reassignment of tasks within teams;
• information on persons, methods and the complexity of solutions is consolidated at one location;
• the evaluation of the status and success rate of projects is much simpler and more accurate thanks to the aforementioned features.

For more sophisticated development work, we use the JIRA Tempo Timesheets Plugin integration. Already in the basic version, JIRA supports time reporting (worklog). The built-in feature will be sufficient for the needs of a small team, while larger teams will probably consider purchasing an extension that allows sorting by teams, projects, etc. Pricing is based on team size, as is usual for the Atlassian ecosystem.

Versioning system

The tasks have been defined, assigned to individual team members and the project picks up steam. The progress of the work must, however, be tracked and changes made by several people must be incorporated into a whole. To this end, we have for years been using the Git versioning system. If you wanted to purchase a version control system in the past, you didn’t have many choices. Certainly, many of you are familiar with Subversion. Today, we cannot but recommend distributed version control systems (DVCS). The most popular such systems worldwide are Git and Mercurial. The choice is a matter of personal preference. If you don’t have any experience with either, in the next article about versioning systems we are looking at the pros and cons of some of these systems. The article discusses in detail the reasons why DVCS is better than the client-server model.

Your developers will deal with the versioning system on a daily basis, so if you have not decided on a particular one yet, you can organise a vote among your developers.

When it comes to price, versioning systems as such are free, unlike data storage.

A central source code repository

A more complicated topic which builds on the choosing of a versioning system is a central source code repository. A web integrator, being a supplier of client solutions, is working on a much greater number of repositories than there are developers on the team. This disproportion significantly affects the costs that the various providers have.

Repositories can be hosted on an internal server or outsourced to a hosting provider. Should you opt to run your own server, you have the choice of using an open-source solution, which requires specific know-how and can be time-consuming to set up, or you can use an off-the-shelf solution with paid support. Last but not least, there is the option of renting server space, in other words, using a cloud service, in which case you pay by the month.

On-premise solution – “what’s in the house?”

When we started with CI, we had our own git server. When it comes to applications, one option is to use free, open-source technologies, which, however, need to be configured. It goes without saying that time is money. You must also factor in the overhead costs associated with the management of IT resources.

An alternative to open-source solutions are paid solutions, which require a relatively large lump-sum investment. Their advantage is that they work out of the box. We can recommend Atlassian Stash, which offers easy and effective management tools and numerous options for managing user accounts and groups as well as Active Directory integration. Alternatives include GitLab, which comes in both community and enterprise versions, and GitHub Enteprise. Apart from price, you should be looking at user comfort, availability of documentation and the liveliness of the user community. Do not go for tools that you have reservations about: choose tools that are intuitive to use.

Rental – on-demand cloud elasticity

A software cloud can expand and contract just like the real cloud. Typical examples of such elastic clouds include Bitbucket, GitHub and GitLab. The advantages of these are:

• non-stop availability from anywhere regardless of internal infrastructure;
• it takes away the worries and hassles of running your own hardware and infrastructure;
• backup, disk space and security are taken care of by a team of experts;
• automatic system and add-on updates;
• you can easily change your provider.

When it comes to price, GitHub is more suited to larger teams that work on a smaller number of projects (products). Such teams appreciate its pricing model based on the number of private repositories. This model would be costly for us.

Bitbucket has a different pricing model based on the number of team users; the number of repositories is not taken into account. For example, to develop an online shop on the Magento e-commerce platform, we would need tens of repositories for the various extensions. We have therefore decided to switch from GitHub to Bitbucket.

A cloud service is more flexible and more comfortable to operate and we can quite easily switch to a different provider of a similar service if such a need arises. However, a cloud solution may turn out to be more costly in the long run.

Deployment of modifications in various environments

The developer has committed his work, i.e., a piece of code versioned in the central repository. Now comes the time to deploy the code in a runtime environment. Application deployment should not be handled manually by the developer; rather, this part of the process should be entrusted to experts on continuous delivery and handled as an automatic deployment task. When a developer commits his code, we call the execution of deployment by a tool that inserts the code in the relevant environment. For more information on deployment, please see the article The advantages of continuous integration and automated deployment.

Project documentation

All projects, however big or small, must be documented. After creating a solution, developers often hand their project over to another team for maintenance. Perhaps we can all agree that without documentation to refer to, work with code that we have not written ourselves can be a headache.

Documentation should always be supplied with any piece of code, although it may not always be sufficient when new developers need to be taken on board quickly. It is advisable that developers create and maintain compact documentation, describing the architecture and implementation of specific functional components of particular solutions, ideally using an on-line system that permits quick viewing and editing of stakeholder groups. We had trialled MediaWiki before switching to Confluence.

One of the reasons for the switch was the option that the latter offered of integrating with other Atlassian systems, not to mention the nice user interface and the flexible security model allowing detailed management of permissions. Unlike Confluence, MediaWiki requires no licence fees, however, the basic version offers only a very simple, open UI with next to no formatting options. As it is a Wiki platform, there is no granular access management. Tens of hours in configuration, extension set-up, etc., are needed and the system may, in the end, come at a steep price.

Which features are important and what makes our life easier?

• import from MS Word documents;
• export to MS Word/PDF formats;
• formatting;
• inserting links and images;
• code documentation;
• support for macros.

Macros are useful tools for the insertion of specific content (e.g. software code) or dynamic content such as child page summaries, etc. Frequently employed and recommendable tools include JIRA integration and filters for viewing task lists.

The filters are dynamic and impervious to the inaccuracy of authors. In the last step, information on activities in Confluence is sent in the form of notifications to topic rooms in HipChat (for more information on the topic of chat see the next chapter).

Real-time communication – chat

You send a group e-mail and the next day you find out that you forgot to include the most important addressee. A client who is unsure whom to address sends an e-mail request to ten people. The message reaches the right addressee, but the other people have received a message that is irrelevant to them.

Not only can this be a bother to some people, but it may be really hard for the employees to stay on top of things if their inboxes are inundated by hundreds of e-mails every day.

Now imagine a chat room to which you can invite a group of people and where everyone can talk without worrying that he or she might have left someone out of the loop. If the ongoing discussion is not relevant to a particular employee, he or she can temporarily log off. If needed, he or she can be invited to re-join later.

As a result, our inboxes are not cluttered with too many internal messages and e-mail, in the end, becomes a tool for external rather than internal communication. A part of our communication with clients also takes place via chat. Chat is useful especially in situations where we need to clarify some details, ideally in real time and involving more people at one time.

We draw information from communication among actual users as well as from other systems we have in place, i.e., JIRA, Bitbucket, Jenkins and Confluence. Unlike the aggregation of information in JIRA, where information is linked to particular tasks, we use HipChat to aggregate information in chat rooms based on teams and projects.

To give you the full picture, here is the cost information: the cost can be calculated quite simply: an organisation running a cloud with unlimited history and message search pays 2 dollars a month per each user.

Integration and standardisation

All Atlassian systems are mutually integrable. This may not be anything special since other systems, including open-source tools, offer this functionality to some extent, however, it is a lot easier to integrate products from one family. It is usually a matter of minutes or hours, at the worst.

Integration is a foundation for an effective mode of work. If you don’t have such integration at your company, we recommend that you take steps in this direction, although the price you will have to pay now and in the future may be a deterrent.

You will spare yourself a headache, save money and improve quality. The transmission and aggregation of information saves a lot of e-mail and personal communication as well as time spent in team meetings. Moreover, you will have traceable history in addition to traditional documentation.

If you have already set about implementing new systems or are preparing to do so, be sure to enlist the help of someone with sufficient experience, e.g. a similar company in the same vertical or an expert consultant. You will spare yourself the headache of learning and implementing a new system and you will also save money.

Last but not least, you will lead by example: the employees of the organisation will be more disposed to accept changes when they see someone who has been through the teething troubles and now reaps the benefits.

You can now follow to the next part – article called: Architecture and operating of web applications in the cloud environment (Part 1).