At Stiltsoft, we recognize how important both our partners and customers are, so we decided to launch our new Partner Program that will affect only the Awesome Graphs for Bitbucket app.
We are building a new Partner Program to provide you with comprehensive training materials and resources, free app licenses, promo codes, and more. If you apply, you save time and effort of your sales team with the help of our training course and demos on demand.
We want to inform you that Awesome Graphs for Bitbucket has Standard Atlassian Partner Discount until March 21st, 2021. From March 22nd, a 20% discount will only be available for Stiltsoft Partners.
Other Stiltsoft apps participate in the Standard Discount scheme for Atlassian Marketplace Products.
To get a 20% discount, you will need to become our partner. Moreover, you will get other partnership perks:
Free licenses
Demo on demand
Promo codes
Enablement materials
App training
Co-marketing activities
To join, simply drop an email at partner@stiltsoft.com, and we will get you set up as soon as possible. For more details, please visit our website.
We look forward to continued collaboration!
Subscribe for monthly updates on how to get the most out of Atlassian products.
Thank you for signing up
for our newsletter!
You will be the first to know about fresh content, releases,
and special projects.
Stay tuned.
Case Study: How a FinTech Company Improves Code Review Process
June 30, 2020
#Case Study#Bitbucket
7 min
We’ve got pretty good with our Pull Request and Code Review process, but initially, our PRs were complex, not very well documented, and difficult to read. The Resolution Time Distribution graph shows how better we are getting at this, being able to merge PRs much quicker than before.
Pablo Reyes, VP Engineering at Strands
Strands is one of our customers that has been using Awesome Graphs for Bitbucket for a couple of years so far. Since 2004, Strands has been developing highly customizable digital money management software for top-tier financial institutions worldwide. Our team is happy to help them reach their goals and improve their development processes with the statistics visualizations we provide.
Pablo Reyes, VP of Engineering at Strands, shared best practices on how their team effectively uses our solution to:
identify bottlenecks in code review
track the process improvement with the implemented changes
increase developers’ motivation by keeping an eye on their performance trends.
Code review process improvement
In fact, they’ve got pretty good with their Code Review process so far. But initially, the PRs were complex, poorly documented, and difficult to read. The Resolution Time Distribution report shows how better they are getting at this, merging PRs much quicker than before.
Since they do a lot of code reviews at Strands, it’s always nice to see who and what teams are making the best use of it. It’s motivating for the team to see the progress, and the Pull Requests reports give them the perfect overview of these advancements.
A couple of years ago, they started improving their code review process. For example, they introduced the practice of approving PRs by at least three people. Moreover, they encouraged developers to leave many comments and suggestions and only approve a PR once it’s good enough.
As a result, PRs are resolved faster, not only because they are done better but also because the quality of suggested improvements rises constantly. The Contributions report gives an overview of code review activity and whether it improves or not.
Software development tracking
At Strands, managers don’t use Awesome Graphs to control the number of commits per developer. Still, they find it useful to look at the dynamics of the overall activity to capture the code development trends. For example, if there’s a significant drop, the developer is probably stuck at difficult tasks or disturbed by various activities, helping other teams or communicating with customers.
Most things are caught soon in the day-to-day communication and work, but mid-term changes in the trend (either a decrease or increase) give them a hint of something they may need to look at. This has been visible when people change projects or teams.
The developer’s Contributions graph gives a clear view of this kind of drops and rises, and it’s handy to compare two periods before and after certain changes were implemented.
Any emerging trend serves as a valuable point for discussion, enabling the team to identify potential bottlenecks or areas that can be enhanced within their software development process. Developers’ performance is complex and depends on lots of different things, some quantitative and some qualitative. Still, the aggregation of code contributions (comments, pull requests, tasks solved, commits, etc) gives some good indicators of how a team evolves with time.
Along with the others, the Contributors graph provides insights into the dynamics of code contributions by different teams and helps with software development tracking.
Try the best teams’ practices for your company
Awesome Graphs for Bitbucket has become a helpful tool for Strands to identify problem areas in their processes and track whether the implemented changes improve them. Besides, it is a handy instrument for regular monitoring of software development.
Introducing New Feature: Graphs for Teams in Awesome Graphs
December 3, 2019
#News#Bitbucket#Reporting#Analytics
7 min
There is no doubt that effective working and communication processes in a team greatly influence the overall success of a product or company. Atlassian products like Bitbucket, Jira, and Confluence aim to improve collaboration and bring distributed colleagues together.
Awesome Graphs for Bitbucket app is our contribution to the teamwork of more than 2,000 companies, as its primary goal is to help identify the bottlenecks in the development workflow and increase the speed. We are eager to make the processes transparent for both developers and managers and, thereby, improve the communication and narrow the gap between them.
We’ve discovered that lots of our clients use similar workflows: they have multiple teams working on the same project or repository. Therefore, tracking the productivity of a particular group that a project or delivery manager, or team lead manages can be tricky as the app showed graphs for all the activity across a project or repository that included the statistics about all the teams together. That’s why we decided to implement a feature that can make their lives easier:graphs for teams.
View the statistics for your team
Teams feature is designed to visualize the statistics about your team performance if there’s a lot of people working on a project or repository. It excludes the contributions of the members of other teams and helps get rid of noisy data.
Configure your teams in the settings and choose it in the All contributors drop-down menu on the Graphs page and analyze how much commits, pull requests, and lines of code a team produces apart from others.
Compare the activity of different teams
If you manage multiple teams working on the same project or repository, you may find it useful to separate their statistics from each other. For example, compare their impact in a codebase of your repository using the Code Frequency graph. That’s what you can easily do with our new feature!
Let’s say you manage two teams: back-end and front-end developers. Open a graph for each team in different tabs and compare their performance.
From the screenshot below, you may identify that your back-end team is continuously deleting the lines of code. They are probably involved in some bug fixing or refactoring activities or implement changes in the API.
Meanwhile, the front-end team has to rewrite some pieces of code to adjust the changes in the backend.
Exclude automated users from the statistics
If you use automation in your repositories, the graphs may show the information that is not related to the activity of your team. Lots of commits and lines of code added by CI/CD users and automated scripts may complicate the performance analysis since it’s not obvious which contributions are made by real people and which of them are not.
Use teams feature to solve this problem by creating a team with all the people you need except for the automated users.
Teams management
A team can be made on the global, project, and repository level by the user with administrative permissions on this level. A team can include whole Bitbucket groups or individual users.
It’s possible to create a global team in the Teams tab in the Administration page and view graphs for it in all projects and repositories.
There’s no need to disturb your Sys Admins from their work to create a team. If you’re a project or repository admin, you may do it in the Teams tab in the settings. In this case, your teams’ graphs will be available only in your repository or project and higher.
Improve your teams’ activity tracking
At the moment, graphs for teams are available only for the Graphs page, but we’ll add this feature to the People page and Reports soon in the next releases.
Try a new version of Awesome Graphs for Bitbucket to get even more useful insights on your team productivity and compare the activities of different teams!
We are delighted to implement the team feature that our customers were asking for, and we hope to make their working process a bit easier and better! So, we appreciate any feedback on the app and suggestions that could help you get the most benefit from Awesome Graphs. If you have any, please, feel free to write to us here as we’re looking forward to learning about your needs!
Subscribe for monthly updates on how to get the most out of Atlassian products.
Thank you for signing up
for our newsletter!
You will be the first to know about fresh content, releases,
and special projects.
Stay tuned.
We have recently released a new app – Submodule Changes for Bitbucket. This free app is created to improve the experience with the Git submodule workflow. No more unreadable pull requests with changes to submodules and skipping the code review process!
Dealing with submodules can be annoying
Our company develops Awesome Graphs for Bitbucket – the app that provides the statistics for projects and repositories and helps to analyze and evaluate development team performance, code review practices and personal activity of each team member. Awesome Graphs for Bitbucket is very popular and has more than 2600 installs on the Marketplace at the moment. It’s available for Bitbucket Server, Data Center and Cloud. We use Git submodules that contain features which are similar for all the versions in order to achieve the fastest delivery.
If you use it in your projects too, you may face the situations when the commits made to a submodule are shown as two hashes in the Diff tab instead of displaying the lines of code, folders, and files that have actually been modified.
It creates the greatest difficulty to the reviewers of pull requests since there’s no chance to review changes and leave comments on the commits of the submodule repository.
Review Pull Requests Easily
If you don’t want to skip such an important part of the development process as the code review, you can try the solution we created: Submodule Changes for Bitbucket. At first, this app came as software that we were using internally, but then we discovered that lots of other developers face similar issues.
Submodule Changes for Bitbucket replaces two commit hashes with the files modified in a commit or pull request. It highlights the changes with a submodule update in the Diff tab as if all of them were made to a parental repository.
The app also gives you the possibility to watch the Blame view, leave comments and suggest improvements in pull requests. It makes the process similar to reviewing changes in the original repository.
Submodule Changes for Bitbucket is a completely free app that can simplify the code review process for the teams that use Git submodules for their projects.
How to Perform Code Review and Track Team Activity in Bitbucket
August 8, 2019
#How To#Bitbucket#Case Study
6 min
Resolution Time Distribution Reports have helped a lot during the development of a high priority module to increase the reviewers, review frequency and also track team activity in Bitbucket.
Eduard Pal, Innoface
Innoface GmbH, one of our customers, is one of the leading providers of interfaces between PDM and ERP systems worldwide. Its applications help ensure a direct and reliable flow of information between engineering and logistics. They also offer additional products and services in order to facilitate seamless integration of the involved systems.
Innoface product development team uses Awesome Graphs for Bitbucket mostly for making data-driven management decisions. They find it very useful to:
track the activity of each developer and a team in general;
check if code review goes according to the plans;
predict time to resolve pull requests.
Let’s see how Innoface benefits from using Awesome Graphs for Bitbucket.
Tracking team activity in Bitbucket
Activity graph helps Innoface have a high-level overview of the total number of commits and contributors in a specific period, for example, a week. It also provides an opportunity to track the number of open pull requests from all the contributors and the repositories.
Using this graph, the manager can assess the activeness of a contributor. This gives the manager an idea of whether an employee is following the company’s development policy or not as well.
Based on the number of open pull requests, the manager in Innoface can actually plan time to review the code and merge them. This graph also gives an opportunity to process the pull requests from the contributors that are working on the high-priority projects.
Analyzing code review practices
Innoface management finds Resolution Time Report very helpful when it comes to tracking the frequency of processing the pull requests.
The manager uses this report in order to see the frequency with which the reviewers are processing the pull requests. Based on the data that this report provides, it’s easier to make a reasonable decision and to assign either more reviewers or increase the frequency of the reviewers, especially for the high-priority projects.
Predicting pull requests resolution time
Resolution Time Distribution report helps Innoface estimate resolution time for future pull requests to make more accurate release dates planning.
The manager of a product team uses this report in addition to the Resolution Time Report in order to estimate the resolution time for future pull requests.
Conclusion
Awesome Graphs greatly enriches the Bitbucket user experience for Innoface. With its help, it becomes much easier to make decisions based on data and keep an eye on how efficient their development practices are.
Read more case studies to see how our customers benefit from using Awesome Graphs for Bitbucket in their work:
Awesome Graphs for Bitbucket: Exclude Files from Lines of Code Statistics
March 22, 2019
#How To#Bitbucket
9 min
Awesome Graphs for Bitbucket is an app visualizing statistics of Git repositories in terms of commits, pull requests, and lines of code. The Contributors graph, and the Code Frequency graph show how many lines of code were added and deleted in the repository in general and by each developer.
Sometimes lines of code statistics doesn’t represent correctly the actual effort and value that developers bring to the repository. For example, if a new library was added, it will bring hundreds of new lines while a task itself was easy to do and took half an hour.
To make your data more precise and informative, there’s a feature in Awesome Graphs that allows the exclusion of files from lines of code (LOC) statistics.
Why Exclude Files from LOC Stats
This feature will be helpful for users, who:
Include source code from third-party libraries, and don’t want to count it towards individual code contributions.
Want automated code generated files not to be included into LOC statistics.
Version a lot of configuration in very large xml files, and don’t want to count their updates as additions of thousands of LOC.
Want to include in LOC statistics only files with selected extensions (i.e. c, cpp, h).
Want to count in LOC statistics only files from the selected directory (i.e. src).
How it works
Repository administrators can add patterns in a gitignore format telling what files have to be excluded from LOC statistics of a repository.
It is possible to exclude:
particular files
all files with selected extensions
all files from selected directories
everything except files with selected extensions
everything except files from selected directories
When an administrator adds or modifies patterns, Awesome Graphs re-indexes the repository and displays graphs with new LOC statistics.
Benefits Examples
You can see examples of this feature usage in public repositories.
Statistics for the main directory of a repository
Let’s view the Contributors graph for the jquery repository. It shows additions of LOC in the whole repository.
The repository exists since 2006, but according to the graph there was no significant activity there till 2014.
It would be great to make the graph more informative and calculate LOC statistics only for the directory containing the main source code – src. We exclude from statistics all files except files from this directory and get a new graph showing the most important activity happened in the key folder of the repository.
Exclusion of files helped to get new insights:
There was intensive activity in 2006-2008, 2011, and 2014.
There was no significant activity after 2016.
Only two of top four contributors to the repository are also in the top four contributors to main source code.
In the first graph there were peaks of activity showing additions of 50K and even 250K lines of code per week. In the second graph the largest peak shows addition of 25K lines of code, others – about 5K. This data represents the real work of developers more accurately.
Exclusion of third-party libraries from statistics
Let’s view the graph for the kubernetes repository.
There are two peaks of activity: addition and deletion of more than 300K lines of code. They represent not actual work, but operations with third party libraries. Huge peaks of additions and deletions caused a large scale of Y axis. Due to this all other activity seems to be non-significant.
Let’s exclude from lines of code statistics files from the directory third_party.
The graph has become more accurate. Peak values disappeared. The scale of Y axis decreased allowing to get a better understanding of the activity in the repository.
