Welcome to our latest episode of Tom’s Tech Notes! In this episode, Tom asks what our collection of industry experts’ favorite use cases and benefits of microservices are.
As a primer and reminder from our initial post, these podcasts are compiled from conversations our analyst Tom Smith has had with industry experts from around the world as part of his work on our research guides.
Containers, led by Docker, burst onto the IT scene in 2013. In the five-plus years since, container technology has reshaped the software development landscape. The shift began with a breakdown of applications into lightweight, independent, and deployable software packages.
Since each container includes everything it needs – code, runtime, system tools, and settings, plus all dependencies, libraries, and other configuration files – you can reliably move containers from one environment to another. For IT teams, this reduces frustration when problems occur due to changes between environments. It also makes the process more efficient, which benefits companies and customers.
Before implementing any DevSecOps tools, you have to embrace that DevSecOps is disruptive to the entire security tool landscape. Too many tools are just putting lipstick on a pig.
But how do you know which ones are lipstick and which ones transform the pig from the inside out? Larry Maccherone laid this out in his talk at our Nexus User Conference. If you’re not already familiar with Larry, he is an industry-recognized thought leader on DevSecOps, Lean/Agile, and Analytics and currently leads the DevSecOps transformation at Comcast. In other words, he knows what he’s talking about.
Software developers have spent the last decade talking about Continuous Delivery and the benefits of delivering working code as often as possible. But it turns out that’s only one part of the whole picture of software delivery. Modern teams actually have three distinct outcomes they are trying to achieve — a holy trinity of continuous, incremental, and progressive delivery. Each of these delivery practices can help your team move faster with less risk.
Continuous Delivery is a set of practices that ensure your code is always in a deployable state. You accomplish this by increasing the frequency at which code is committed, built, tested, and deployed-steps that in the past only occurred at the end of a project when it was ‘code complete’.
Tanu McCabe’s expertise as a solutions architecture director at Capital One has enabled her to lend invaluable insights about her exciting adventure within the company’s digital journey. Since 2015, Capital One, one of the country’s largest banks, has championed a large-scale tech transformation. During an interview, Tanu reflected on her decision to join Capital One, her hopes for the future direction of the company, and how burnout brought her to a dream job in DevOps.McCabe’s job as a solution architect allows her to provide leadership and guidance that leverages the latest technological developments. As part of her job, Tanu positions the company on the best solution designs, projects, and company-wide initiatives.
How did you decide to come to Capital One?
In many projects, the product development workflow has three main concerns: building, testing, and deployment. Each change to the code means something could accidentally go wrong, so in order to prevent this from happening developers adopt many strategies to diminish incidents and bugs. Jenkins, and other continuous integration (CI) tools are used together with a source version software (such as GIT) to test and quickly evaluate the updated code.
In this article, we will talk about Jenkins, applicable scenarios, and alternatives to automated testing, deployment, and delivering solutions.
The trends in software development are showing that more and more companies are adopting CI/CD methodologies to deliver their software applications. We all know that the market demands quicker releases. The days of waiting for months for new releases are gone. Software is now being released at record speeds! Adopting CI/CD does just that. It helps get your application out the door to the market as often as possible. However, one key aspect that seems to be overlooked is Continuous Testing. It’s great that CI/CD is getting software out quicker but quality should not be sacrificed. To solve that you have to test early, test often! Adding a culture of Continuous Testing to your model will provide the following benefits because now you’re focused on testing from the beginning of your SDLC
Now that we know to truly have a CI/CD methodology you need continuous testing as well. But just like adopting CI/CD, continuous testing requires an organizational culture shift. So how do you build that culture? It’s a different mindset that relies heavily on automation: Automated Unit Tests, Automated Functional and Non-Functional Tests, Automated Regression Tests, and Automated Deployments. Basically, anything that can be automated should be automated! That is the key principle of Continuous Testing, test from the beginning and automate as much as possible to ensure faster release cycles.
We all know the practice of continuous integration.
One of the common pitfalls of CI is that the build status is not monitored and not treated as one of the top priorities for the team.
Recently I gave a talk at Agile Testing Days USA in Boston, my first time attending this testing conference and I was extremely pleased with the event, the things I learned, and the people I had the opportunity to meet. For example, I got to know some of my Agile testing role models: Lisa Crispin, Janet Gregory, and Rob Sabourin, among others.
(If you’re already familiar with performance testing and the concept of continuous integration, go ahead and skip this part!)
