If you search “test driven development” on Google, chances are you will come across well-written, insightful blogs from development companies explaining what Test-Driven Development (TDD) is. They will explain how test cases are designed based on requirements before programming begins and software is written so as to pass all those test cases.
At Calavista, we were interested in DevSecOps before there was an overall term for these best practices in software development. We were founded on concepts such as Continuous Integration and Continuous Delivery, pioneering Agile development. Since the early 2000s, the software development and DevSecOps scene has changed dramatically, exploding with new technology to help streamline […]
At Calavista, we were doing DevOps before it had a buzz-word title. Likewise, we’ve been doing DevSecOps for quite some time, and it’s about time we start calling it what it is.
Our previous blogs have defined DevOps as a collaborative culture with its own defined practices, ideas, tools, technology, processes, and metrics. Integrating some of these elements into your workflow can help streamline and improve your development process.
DevOps has made it possible for organizations to develop and release stable applications faster than ever. However, and organization with a proper DevOps pipeline should always include Continuous Monitoring through the development lifecycle.
Test Driven Development (TDD) is a development practice where developers author code by first describing the intended functionality in small, automated tests, then writing the necessary code to make that test pass.
In the last decade, we have seen significant shifts in software development operations. One of these shifts is the evolution of DevOps, which came into play in 2008/9.
One of our projects at Calavista right now is helping a client modernize and optimize a large .Net application, with the end goal being everything running on .Net 5 and an order of magnitude improvement in system throughput.