There are many different systems available for task recording, document generation, team communication, and deployment. This article’s second instalment will demonstrate how these tools may be used to create a productive system. You can get a lot of advantages by integrating these otherwise independently operating tools.
You should not forget to read the first article in this series regarding web integration – Continuous Integration (CI) in Practice – #1.
A PROJECT MANAGEMENT AND ISSUE-TRACKING SYSTEM
An issue logging and tracking system are essential for all projects, whether they are post-sale applications or brand-new initiatives. Before your developers begin writing code, you must specify the tasks to which you will allocate specific programmers, i.e., tasks progress and expense of which can be tracked against objectives.
We previously used Mantis Bug Tracker at Onlineandweb.com, however, it no longer meets the needs of today’s software project management. It is an excellent, though rather complex, problem-recording system, but it lacks many essential functionalities that we want today.
Without a flexible bug management solution that actively encourages the use of agile development management techniques, modern application development is impossible. The JIRA issue tracking system, which we currently use, offers the following advantages over Mantis:
- It is user-friendly
- It may be simply set to interact with other tools (such as HipChat IM, Confluence, and Bitbucket.org)
- It is possible to customize project workflows
- It supports teamwork (user access and role management system)
- It combines the functionality of an issue tracker with a time tracker
JIRA is expensive, like other Atlassian products, however, we presently use it to replace two systems (issue tracking and time reporting). JIRA effectively saves us time because it is quicker and simpler to use. Additionally, one of the systems was specifically created for us, which will enable us to significantly reduce future development, servicing, and bug-fixing expenses.
The JIRA system should be linked to a central source code repository, allowing users to dig deeper to learn more about the work that has been completed and its authors. We have access to the relevant technical details of the implementations in addition to the verbal comments made by team members.
The selection and implementation of an appropriate workflow are crucial factors. The installation of JIRA provides certain pre-built workflows, although these do not perfectly match the procedures used in software development.
JIRA’s fully customizable processes may be both a benefit and a problem. Although this independence may have certain advantages, you must nevertheless capture recurring events and procedures that are typical of most projects. Workflows that are adaptable to multiple projects must unavoidably involve certain compromises. The further you go into the configuration choices, the more probable it is that you will be able to satisfy unique requirements and establish custom workflows. This has more drawbacks than benefits. A lower number of workflows helps in orientation; statuses (To do, done, accepted…) and other attributes should be standardized across projects to minimize misunderstandings in communication and process management. Managers and developers both find it easier to navigate a small number of universal procedures rather than dozens of customized workflows. As a result, we have adopted the usage of workflow schema definitions, which may be properly prepared for the organization and from which users can select when creating new projects.
Although user-friendliness is not the major criterion, a decent GUI saves time and stimulates staff to utilize the system with respect, if not joy. On-site editing, search, autocomplete, and keyboard shortcuts are all excellent features!
We previously had a time-tracking system that was established separately from the issue-tracking system. It was a system that we created and constructed ourselves. However, we could not keep developing it constantly, and upgrading it to match our changing demands would have required the creation of a new program.
The following are the benefits of merging the two systems into one:
- Less time is spent on task tracking, reporting, and reassignment within teams.
- Information about people, methods and the difficulty of solutions is centralized.
- A single system stores linked information on bug logging and bug resolution progress.
- Because of the aforementioned capabilities, evaluating the progress and success rate of projects is considerably simpler and more accurate.
We use the JIRA Tempo Timesheets Plugin connection for more complex development tasks. JIRA already provides a time reporting in its basic version (worklog). The built-in functionality will suffice for a small team’s needs, but bigger companies may consider obtaining an extension that permits sorting by teams, projects, and so on. Pricing is determined by team size, as is typical in the Atlassian ecosystem.
The tasks have been specified and assigned to individual team members, and the project is growing bigger. However, the progress of the work must be monitored, and adjustments made by several individuals must be incorporated into the overall picture. To that aim, we have been utilizing the Git versioning system for years. In the past, there were few options for purchasing a version control system. Many of you have probably heard about Subversion. We can no longer suggest distributed version control systems (DVCS). Git and Mercurial are two of the most popular systems in the world. It is up to you whatever option you choose.
If you have not chosen one yet, you may organize a discussion among your developers who will be working with the versioning system daily.
Versioning systems themselves are free, in contrast to data storage, which involves an expense.
A CENTRAL SOURCE CODE REPOSITORY
A central source code repository is a more complex problem that relies on the selection of a versioning system. As a provider of client solutions, a web integrator is responsible for many more repositories than the team’s developers. This gap has a considerable impact on the expenses that the various providers face.
Repositories can be hosted internally or by a third-party hosting service. If you decide to operate your server, you may choose an open-source solution, which takes a comprehensive understanding and can be time-consuming to set up, or you can choose an off-the-shelf option with paid assistance. Finally, there is the alternative of renting server space or using a cloud service, in which case you pay by the month.
We had our git server when we first started using CI. In terms of apps, one alternative is to use free, open-source technology, which must be adjusted. Time is money, it goes without saying. You must also consider the overhead expenses involved with IT resource management.
Paid solutions, which demand a relatively big lump-sum investment, are an alternative to open-source solutions. Their benefit is that they think outside the box. We recommend Atlassian Stash, which provides simple and effective administration tools, a variety of choices for managing user accounts and groups, and an Active Directory connection. GitLab, which is available in both community and corporate editions, and GitHub Enterprise are two alternatives. Aside from pricing, you should analyse user comfort, documentation availability, and the dynamism of the user community. Choose tools that are easy to use rather than things that you have reservations about.
On-demand cloud elasticity
Like a real cloud, a software cloud may grow and shrink. Bitbucket, GitHub, and GitLab are common instances of such elastic clouds. They have the following benefits:
- Automatic system and add-on updates.
- It is simple to switch providers.
- It eliminates the difficulties and concerns associated with maintaining your own hardware and infrastructure.
- It is available from anywhere regardless of internal infrastructure.
- A group of professionals handle security, backup, and disk space.
In terms of cost, GitHub is better suited to bigger teams working on fewer projects (products). Such teams value their price approach, which is dependent on the number of private repositories. This model would be too expensive for us.
Bitbucket’s pricing approach is dependent on the number of team members; the number of repositories is not considered. To build an online store on the Magento e-commerce platform, for example, we would need tens of repositories for the various extensions. As a result, we’ve chosen to switch from GitHub to Bitbucket.
A cloud service is more adaptable and pleasant to use, and we may quickly move to another provider of a similar service if the need arises. However, a cloud solution may end up being more expensive in the long term.
DEPLOYMENT OF MODIFICATIONS IN VARIOUS ENVIRONMENTS
The developer has committed his work, which is a versioned piece of code in the central repository. It is now time to run the code in a runtime environment. The developer should not manage application deployment manually; rather, this aspect of the process should be delegated to professionals in continuous delivery and managed as an automatic deployment activity. When a developer commits his code, we refer to this as deployment by a tool that puts the code into the appropriate environment.
All projects, no matter how large or little, must be documented. Developers frequently hand over their projects to another team for maintenance after generating a solution. Perhaps we can all agree that working with code that we haven’t developed ourselves can be difficult without documentation.
Documentation should always be provided with each piece of code, but it may not always be sufficient when new developers must be brought on board rapidly. It is recommended that developers write and maintain concise documentation explaining the design and execution of specific functional components of specific solutions, preferably utilising an online system that allows for easy reading and modification of stakeholder groups. We tried out MediaWiki before choosing Confluence.
One of the reasons for the transition was the latter’s ability to integrate with other Atlassian systems, not to mention the attractive user interface and flexible security model that allows precise permission control. Unlike Confluence, MediaWiki does not require a licence cost; nonetheless, the minimal edition only provides a very plain, open UI with few formatting choices. There is no granular access management because it is a Wiki platform. Tens of hours of configuration, extension setup, and so on are required, and the system may end up costing a lot of money.
- Code documentation
- Export to MS Word/PDF formats
- Inserting links and images
- Support for macros
- Import from MS Word documents
Macros are helpful tools for inserting particular material (like software code) or dynamic content, like summaries of child pages, etc. JIRA integration and task list filtering are technologies that are frequently employed and recommended.
The filters are dynamic and resistant to author inaccuracy. Finally, information about Confluence activity is transmitted to HipChat topic rooms through alerts.
The day after sending a group email, you realise that you failed to include the recipient who was the most crucial. Uncertain of whom to contact, a client emails 10 recipients with a request. The correct recipient of the message receives it, while everyone else receives a message that is irrelevant to them.
Not only does this annoy some consumers, but it can also make it difficult for employees to stay on top of things if their inboxes are flooded with hundreds of e-mails every day.
Consider a chat room to which you can invite a group of individuals and where everyone may discuss without fear of leaving someone out of the loop. If an employee feels that the current debate is not relevant to him or her, he or she might log off momentarily. He or she can be invited to rejoin later if necessary.
As a consequence, our inboxes are not overloaded with internal communications, and e-mail eventually becomes a tool for outside communication rather than internal communication. Chat is also used for some of our client interactions. Chat is extremely important when we need to clarify certain points, ideally in real-time and with several persons involved simultaneously.
In addition to other systems we have in place, such as JIRA, Bitbucket, Jenkins, and Confluence, we gather information from communication among actual users. We use HipChat to aggregate information in chat rooms based on teams and projects, in contrast to the information aggregation in JIRA, where information is linked to specific tasks.
Here is the cost information to give you a complete picture: it is quite easy to determine the cost: a company using a cloud service with limitless history and message search spends $2 per user per month.
INTEGRATION AND STANDARDISATION
Atlassian systems may all be integrated with one another. This is not unique because other systems, including open-source tools, provide some of the same capabilities; nonetheless, it is much easier to combine products from the same family. It is normally only a matter of minutes or hours at most.
Integration is the foundation for an efficient method of operations. Even if your company does not have such integration, we propose that you take steps in this direction, although the cost you will have to pay now and, in the future, may be a deterrent.
You will save time, and money, and increase the quality of your work. The transmission and aggregation of information save a significant amount of e-mail and personal communication time, as well as team meeting time. In addition to typical paperwork, you will have a traceable history.
If you have already begun or are planning to begin adopting new systems, make sure to seek the assistance of someone with adequate expertise, such as a similar company in the same sector or an experienced consultant. You will save money while avoiding the headaches of learning and deploying a new system.
Last but not least, you will set a good example: employees will be more willing to accept changes if they witness someone who has gone through the process and is now enjoying the results.
You may now go to the next section – an article titled: Continuous Integration (CI) in Practice – #3.