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.
Using Confluence as the place for dashboards allows you to achieve better end-to-end visibility: it enables merging and aggregating data from different sources and makes it easily accessible to Leadership. Furthermore, you can export the reports in PDF, Word, JPG, or print them out and email them to external users, attach them to the quarterly report, or distribute them to managers and stakeholders.
Today we want to show how you can enhance your reports built with Table Filter and Charts for Confluence by adding engineering metrics from Bitbucket using the Awesome Graphs for Bitbucket app and build dashboards for PMs and stakeholders in Confluence. These metrics make up a comprehensive view of the processes and help managers make informed decisions.
Commits by User Chart
This chart is aimed to show you which developer worked on which project and their level of activity in terms of the number of commits so that you can identify the top contributors for each repository. You can also find the most active repositories in the whole instance, particularly for a specific project. This data can help you decide which repositories to target first with particular process improvement.
Hint: add the Table Filter macro before the Chart from Table to select repositories for comparison.
Check out a full guide on how to build this chart.
Commits Dynamics Chart
There may be cases when the snapshot is not enough, and it’s necessary for planning to see the actual change in progress. To examine trends over time, you can build the chart that will show the dynamics of contributions made by users over the chosen period. Using this, you can then compare the periods and answer questions like “Are we committing more code now than before?”.
Hint: you can change the grouping to daily, weekly, or monthly by changing the Date period aggregation in the Pivot Table macro settings.
Another way to get a better understanding of the amount of work done across the projects and measure the activity and efficiency of the teams is to look at the number of lines of code added and deleted. On this chart, you can see the visualized statistics of the user’s activity in terms of lines of code on the project level.
Hint: use the Chart from Table macro’s feature “Chart as image” to save the chart as JPG and email it or use it in PowerPoint presentations.
To complete the picture, you can use the two following graphs showing the Pull Request activities of the developers, i.e., the number of Open, Merged, and Declined Pull Requests on the project level basis.
The first chart provides you with an organizational view and allows you to visualize the statistics across multiple or all of the repositories, grouping the Pull Requests by their state.
You can then drill down for more detailed data and build the chart to discern the output and productivity of each particular user:
Hint: You can also build the chart to see the dynamics in Pull Request activities by following the instructions from Commits Dynamics Chart, but with the Pull Requests source file.
Using the charts described in this article, you can analyze engineers’ activity and productivity, evaluate the capacity to work, and make data-driven decisions to improve engineering efficiency.
The combination of these apps is capable of building much more complex structures that would allow you to aggregate all the information in a single dynamic chart, where you could choose and change the components on the go to get different visualizations each time in a few clicks.
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.
How to use statistics to overcome challenges when moving to microservices
April 30, 2020
#How To#Confluence#Bitbucket#Analytics
10 min
Agile software development has been dominant in software engineering for years. Its methods have helped teams manage work and perform efficiently while delivering high-quality results. Microservice architecture is one of the approaches that implements the Agile practices:
Microservice architecture is a style of structuring large complex products as a collection of individual services that can be developed and maintained independently, making the software more flexible and increasing its scalability.
While microservices may seem as a silver bullet upfront, nothing comes easy. The migration can result in deployment challenges as well as make global testing and debugging more difficult. Apart from purely technical side effects, it requires a cultural shift in organizations and strong project management.
In this article we focus on the challenges related to the management of microservices and describe the ways to overcome them using aggregated data and statistics:
We’ll teach you how to turn your Confluence instance into a full-fledged BI tool and how to:
identify dependencies between teams
see if there is a lack of collaboration between members
find pilot teams to implement new processes in
check if you are actually moving away from the monolith.
Imagine now that you have a hostel marketplace application where people can find and book a stay. Recently you’ve decided to migrate to microservices, so now the whole application is split into independent services, each having its own repository, and you need to organize your teams and the processes the right way.
Resolve dependencies and build the teams
When done correctly, microservices work so that you can build, test and deploy them without affecting each other. To achieve that you need to recognize and then eliminate dependencies between the teams.
For that purpose you can build the following graph and see the distribution of contributors on the project level:
The graph shows the number of commits made by users, so you can identify service owners, see the interactions between the members of different teams, and spot deviations in terms of who does what, e.g. if there is somebody from the team A working on the team B’s service. The latter can result in delays in the development process and an increase of idle time caused by lags in communication between the developers.
The same graph can also indicate the anti-patterns in teams’ culture. Being a member of an independent team can help developers work more effectively. But some teams just lack the concept of collaboration. So instead of having the work distributed among the developers, it happens that only the so-called “service owner” ends up working on his microservice. In addition to a drop in the morale of the developer, this may affect the quality of the code as there is nobody to review it.
You can use this graph to find services led by one person and then make informed decisions to improve the team culture.
Experiment without risk
The variable development processes and independence are clear benefits of microservices architecture. Teams don’t have to align with the others and that allows you to test and implement new processes without paralyzing the workflow even if something goes wrong. This way you can try to introduce new practices to improve the quality of your software, such as unit testing, code review, pair programming, you name it.
To start the implementation of the new processes it’s important to find the teams that have been operating efficiently and are currently active. The number of commits and pull requests can be used as an indicator of the active state.
The two following graphs will help you to find pilot teams to hold experiments:
The graphs show the activity of the teams by month for the last quarter, indicating the number of commits and pull requests respectively. Now you can compare the results and find the teams that have a lot of commits and none or few pull requests — those will be your perfect candidates.
See the monolith breaking
Moving from the monolithic systems takes a lot of effort so it’s important to keep track of where you are in this journey. Apart from staying motivated as you see the changes (or not yet), you need to make data-driven decisions to improve the processes and lend support to your teams.
To get the full picture you may use the graph that shows the changes in the codebase:
It displays the number of lines of code deleted and added around the project. Using this information you can see the breaking of the monolith: if the number of lines of code deleted is increasing steadily for the monolithic repo while more and more lines of code are being added to the new microservices repos, then you are going the right way.
Make the data work for you
While migration to microservices may seem costlier in terms of the amount of work for managers, that is the investment that will pay you back with faster development processes, increased scalability and adaptability. And we hope to make your way easier here.
The tips described in this article will help you gain more visibility into the current state of the processes and unleash the potential of your teams. Using the Awesome Graphs for Bitbucket app as a data provider and the Table Filter and Charts for Confluence app to aggregate and visualize the data, you will get the functionality that is on par with dedicated BI software platforms.
Want to know how to build the graphs and charts from the article? Read our step-by-step guides and try yourself!
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.
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.
How Engineers Analyze Code Review Practices in Bitbucket
November 9, 2017
#How To#Bitbucket#Case Study
9 min
This is a fantastic plugin, really useful to analyze code review practices, monitor individual repo activity or a developer’s activity across multiple repos. Looks and works great!
Philip O’Gorman, JCA Electronics
JCA Electronics specializes in designing and manufacturing electronic control systems that are used by original equipment manufacturers (OEM). Their engineering team creates embedded drivers, embedded application software, mobile application libraries, and mobile applications for many OEMs that are mainly agricultural and construction companies.
The team uses Bitbucket for collaborating on code and extended its capabilities with the app Awesome Graphs for Bitbucket to:
get the history of developer activity across all projects and use it for filling in timesheets
browse commits of all branches of a repository
analyze project activity and the process of code review
Data for billing – a click away
JCA Electronics’ engineers can be working on many projects simultaneously. Therefore, to fill in timesheets for billing, the company needed an easy way to see the daily work log of each developer.
They found Contributions in user profiles invaluable for this purpose, as this page shows a developer calendar of the past year. When they click a day, the activity stream shows the list of commits and pull requests across all projects for that day.
Commits across all branches
In addition, JCA Electronics appreciates the capability to see the activity across all branches (‘Show all’ link) on the Commits page of a repository or project. Before, they could only view the commits of each branch individually.
In addition, there’s a commit graph that gives a visual representation of the development flow and makes the commit log easy to read.
Project activity – at a glance
The team uses project graphs and reports to analyze project activity and monitor the number of contributors. The Graphs’ Activity tab provides the charts that let you compare the input (number of commits and pull requests) from the most active developers. In addition, it features the activity stream with the feed of commits and pull requests of the project.
The Contributors tab captures the dynamics on two levels: team efforts (green graph) on the project and contributions of individual engineers (cards with red graphs).
The Contributors page can show graphs in commits, lines of code added or lines of code deleted. So a project manager can analyze the progress of development from different perspectives.
JCA Electronics also uses Top Committers Report to see what developers worked on a project during a certain period of time, e.g. a sprint, a year, and compare the number of commits each person contributed.
Tracking code review practices
The company has many projects and repositories to manage. So it is very important for them to make sure that pull requests and code reviews are utilized on each project. Activity in project graphs and Created vs Merged Pull Requests Report help the team ensure that the correct practices are being used.
Activity shows:
how many pull requests were created, merged, and declined in the project within a chosen time period
who made those pull requests, including whose pull requests were declined
what developers were more active than others
Created vs Merged Pull Requests Report visualizes the dynamics of pull requests’ creation and merging that tells the team:
pull requests are used a lot (the curve is rapidly heading away from the Time axis) or not
more pull requests are being created than merged (red parts of the graph) or vice versa
how many pull requests were created and merged in each period
Conclusion
The Awesome Graphs for Bitbucket app provides JCA Electronics with the capabilities that enrich and facilitate their experience with Bitbucket. The company benefits from graphs and reports that give insights into project activity and code review practices. The graphs also provide data for billing and evaluation of contributions made by teams and individual developers.
Read more case studies to see how our customers benefit from using Awesome Graphs for Bitbucket in their work:
5 New Add-ons for Dev Tools at Atlassian Marketplace – First Quarter 2017
May 18, 2017
#News
1 min
The spring is in blossom and new products are blossoming at Atlassian Marketplace. We’ve already shared our selection of top 5 new add-ons for Confluence and JIRA with you. Now let’s take a look at what’s new for Dev Tools (Bitbucket and Bamboo). We reviewed the add-ons that were launched at the Marketplace during January-March this year and chose 5 that we thought might be especially interesting and useful for our readers. Continue reading “5 New Add-ons for Dev Tools at Atlassian Marketplace – First Quarter 2017”
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.
