Somos is a proven leader in registry management and data solutions. Somos fosters meaningful connections by delivering value, innovation and confidence to consumers. We have talked with Gary McKay, Somos’ Director of Agile Service Delivery, to better understand what made the company opt for Codacy as their automated code review tool, what were their main needs, the key issues tackled and the benefits they found. Somos uses Go, Java and NodeJS as their primary programming languages, and GitHub as their git provider.
How long have you been using Codacy, and what were the main needs that led you to implement it in your team?
We have been using Codacy for two years. We were trying to find something that would work in a more microservice-based and cloud-native world. We wanted something that was not only flexible but also more modern than other static code analysis tools we were using. After further research and proof of concepts, Codacy came on top.
Can you tell us a little bit about why you chose Codacy for your code review needs?
We were looking for a tool that could help us automate code reviews that was efficient and reliable. In the past, other tools we used were cumbersome. When updates were deployed, we would have to make sure that the update didn’t break our configurations. It became hard to manage. We needed a solution that wasn’t going to create more work for us by breaking our builds.
If you look at Codacy, it differentiates itself from the others on innovation, and that’s what we need. We want to make sure that the products that we have in our stack focus on innovation, not just small changes but really innovate. We made an investment in Codacy because we saw that the company is going to be an industry leader, and we want to make sure that we have the best of breed in our stack.
Can you compare how your workflow is today with how you were working in the past?
The last tool that we were using didn’t work well with microservices. Even though we ran it in AWS, it wasn’t AWS native and it wasn’t cloud native. We tried to leverage the tool to work in a more spring boot microservice approach and serverless environments; it didn’t work well.
As we integrated Codacy more and more and began migrating our larger applications into the cloud, we just switched over. It didn’t make sense to support two different tool sets and when we plugged Codacy into the pipeline it’s like, “I got it, don’t worry about it, that’s what we do.”
The tool integrates easily into our pipelines and considering that we’re migrating all of our applications into the cloud, this makes a difference. Codacy is more cloud native and microservice-based, which makes it a good fit for us.
Something I like about Codacy is that we feel that we’re not just another customer. I think the tool has enough depth and stability that as Codacy grows, we will always be sort of one of the first customers. Even if we weren’t, the way that the team treats us, it is like we are Codacy’s only customer – and I know it’s not true but I like that. I also appreciate the fact that your team is really responsive.
What were the main issues you’re trying to tackle?
The one thing that Codacy does very well is the way that it lays out the UI. The combination of the reports and analytics makes it clear what’s really going on in your projects.
In the old stack, our application was sort of monolithic, we couldn’t deploy one piece or one module, we had to deploy the whole thing.
The main issues that we are addressing by adopting Codacy are:
- Performance: we have a number of projects that are going through Codacy, and the speed of analysis for microservice-based applications is important for our team.
- Ability to set dynamic thresholds: this is one thing we like about Codacy, we don’t have to hard code stuff, we can set ranges in the quality gate on the UI. We set thresholds to make sure that when our code comes through, that we can break the build if those thresholds are not met.
- Efficiency: we needed to make sure that our engineers and DevOps engineers weren’t spending a large amount of their time just trying to configure the tool.
What impact has Codacy made on the issues you were trying to tackle?
What Codacy has done is lessen the impact. Anytime we bring a new tool into our stack, there are always learning curves and consequences. Codacy has made that transition seamless enough that it didn’t have a negative impact and it performed better. The ROI and value statement is all positive so why wouldn’t we bet on Codacy?
In our group, we have our core engineers (the Jewels, as I call them – I love my team!) and in addition, we have vendor partners. It is critical that we ensure our teams can use the tool effectively without cutting corners. On Codacy you can’t cut corners:
- You can’t change the thresholds without us knowing that you changed them
- Codacy makes it clear about which problems you have, you can see it on the dashboard, the reporting and analytics feature
Is there any particular benefit that impressed you the most?
One of my favorite features is the dashboard, reporting and analytics feature. I don’t have to drill down into the code base, I just need to provide tools in the stack so engineers and architects can do that. What I need to make sure is that when I look across the reporting and analytics, I can see from an enterprise perspective how things are going:
- What’s the code quality look like?
- Where are our problem areas?
- Are those problems consistent?
One thing we saw last year was this sort of curve of inconsistent problems, the reporting and analytics feature provides us with the data we needed to analyze the issue and figure out what was going on. We’re able to do that and to see the trends overtime. The trend is your friend, you’re able to see those things.
You mentioned that we are a modern SAST tool, why do you think this?
It is the UI, that’s the first thing people see. The UI is very modern and attractive compared to other tools which are kind of dated now. It’s just not another pretty tool, Codacy has built a tool that has a depth of feature richness and it looks good. There’s a lot of depth behind that.
If the architects, developers and engineers on the Somos team will be spending time using the tool, then it needs to look good, be functional and highlight where they can get things without requesting help.
Why do you like working with Codacy?
Your team probably doesn’t get enough credit but if I submit a question or have an issue, you are really responsive: we don’t have to call your help desk or wait 48 hours. If you don’t know the answer, you’ll go find out or set up a call so we can talk through it, that’s impressive especially considering that you’re in Europe because it doesn’t feel that way.
The back office is really important, I need to make sure that when we’re having issues or we have questions that we get a response because my team is on the front line.
Thank you Gary, it was a pleasure talking with you – love your energy and enthusiasm!
Gary is Somos’ Director of Agile Service Delivery. He was previously Scrum Master and Release & Deployment Manager. Prior to joining Somos, Gary was an independent consultant focusing on Agile Development, DevOps, Technology migration and governance. He has worked for many large organizations, including Fannie Mae, DoD, TIAA-CREF and other large organizations. He has over 30 years of experience in Software Development, Agile, systems analysis and Program Management.
If you’d like to hear more from our customers, you can read our clients’ stories here. To learn about Codacy and our plans, please visit our page, with the pricing and breakdown of both Pro (Cloud) and Self-hosted plans.
