Started as a tool to help with very small part of engineers routine, Codeventory is designed as a system to cover all aspects of code ownership.
Usual workflow within the software system, which has already developed for a few man/years and more, in addition to the well-known development phase, introduces new problems to solve.
While it’s a straight forward process, with the growth of codebase itself and development teams, there might be following challenges to overcome.
Change may be huge to read (say +2k -1k lines in 30+ files), even you split work into smallest possible pieces
Another team may develop change, so you have less context, even talking to each other
It may include unplanned work - rewriting and refactoring are the most common cases
Available tools provide mostly line-by-line comparison, that’s why we step further to advanced visualization and explanation of what happened to the system as a whole.
Information on a new feature and it’s acceptance criteria usually provided by the work item, like story or task. However, there is one more time-consuming area that requires communication between development and QA people. Regression testing or speaking different words, ensuring that already delivered features not broken accidentally.
Here we face the following problems:
Developers need time for impact analysis
Changes, especially, in core components that impact the entire system, may not be seen or forgotten, due to human error
There might be changes done by different teams, so additional communication and entropy levels may join to the process
In addition to the application architecture diagram that highlights changed components, we plan to add a report, convertible into a test plan, almost at no cost.
Once all changes are done and confirmed, it’s time to form a software system’s release candidate.
At this moment, we already have a cumulative changeset with all features and fixes developed for some period of time, from few weeks to months.
It’s time to form release notes and sign approvals, which may be complicated.
Engineers may include changes not linked with work items - closed stories or tickets
While we trust code review of a single feature or fix changeset, developers, that participate in this process, may not pay attention to changes crucial for the upper management - database schema or public API’s updates, or completed features which should go into next release, not the current one, may put the product at risk
With Codeventory, it becomes much easier to see which tickets included in the release and have the context of what happened to a system.
Technical debt increase
Continuously adding code, we add complexity also.
Not paying attention to this problem causes products to lose speed, even spending times more on development.
As a result - lost competition and positions in Gartner Quadrant or Forrester Wave.
The solution will come with Codeventory 2.0 release in mid-2021.