Towards a 3-step software development cycle – The New Stack
Rishi Yadav is the co-founder of Roost.ai, which provides instant and ephemeral production-like environments and closes the distance between development and production. Rishi has over two decades of experience in enterprise application design and development. He is an expert in open source software and advises companies on the latest technology trends. Rishi was honored as one of Silicon Valley’s 40 Under 40s in 2014 and has written two books on Apache Spark. He graduated from the Indian Institute of Technology (IIT) in Delhi.
As an industry, our overall goals are to produce the highest quality software possible in the shortest possible time. For the past two decades, most organizations have used a five-stage software development life cycle (SDLC) to give teams a way to ensure high quality and catch as many issues as possible before production.
On the other hand, most people see these goals as conflicting with each other. If you want to build extremely reliable, high-quality software, it’s going to be relatively slow; if you want to prioritize speed, you will inevitably have more switch failures and resulting outages.
The way we have managed these competing pressures over the past two decades has been with a development lifecycle that spanned from development to testing to integration to staging to production. Between the development phase and the “real world use” phase, there are three environments dedicated to detecting problems that would cause the software to operate differently in production.
Two critical phases: Development and manufacturing
The truth is that the most important phases of the life cycle are development and production. Development is where the application comes to life; production is where it actually lives. The software development lifecycle should focus on these two stages, the beginning and the end, and help applications move from one to the other as quickly and efficiently as possible. A five-stage software development lifecycle places too much emphasis on the testing, integration, and set-up phases of an application’s life. Equally important, compared to more modern cloud-native approaches, this type of lifecycle is slower and more error-prone – exactly what we want to avoid.
Rethinking the phases
Ideally, we would be able to get all the software ready for production before leaving the local developer’s machine. In reality, it makes sense to have an intermediate stage between development and production to ensure that the application has a chance of being evaluated by someone other than the original developer before entering in production. But there’s no reason why this step requires three separate environments — one middle environment should suffice. I think a good name for this environment is “production-like”, which makes the software development lifecycle development —> similar to production —> production.
The key to making this work, however, is to ensure that developers are as empowered as possible to test their apps – and that the development environment and staging environment are both as similar to production environments as possible. . The goal is to ensure that developers are able to test as many sources of problems as possible so that the production-like stage is devoted to handling tests that developers cannot practically perform, such as involve production data, ensure configurations are correct and test load.
Improve developer confidence through committing changes
No one wants someone else to find the flaw in their code, but at the same time, developers aren’t crazy about running tests, whether that means writing tests or doing manual tests. But developers shouldn’t have to ship their code to a test environment to find out if it works or not and worry about the embarrassment of having a colleague find an error.
Robust change validation does exactly that: it allows developers to catch potential errors before the app or update leaves the local environment. Committing changes involves not only testing that the code is good, but also that it works as expected with all dependencies. When a change goes uncommitted, the developer knows immediately and can fix the issue and try again immediately. And when a change is committed, the developer can push the code into the production environment with confidence, knowing that it’s been tested against upstream and downstream dependencies and won’t cause anything to break. unexpected way.
The idea is for as much hardening as possible to occur in the development environment so developers can ship with maximum confidence. As code moves from development to production, it goes through a change validation tool that can ensure it works with all dependencies before moving on to the next stage.
What happens in the production environment?
Once we’re in the production phase, it’s time to make sure that all environmental factors and configurations have been checked and that everything is integrating appropriately with dependencies.
In an ideal world, the service should be treated as a first-class citizen in a production environment. This is not how most continuous integrations currently work. During the production phase, the focus should be on how requests move between services and how interactions are handled, not just whether or not the code is strong.
Reducing the distance between development and production is a way to simultaneously improve development speed and reduce change failure rates. Switching to a three-stage software development lifecycle does just that. It also has the added benefit of giving developers more control over testing and hardening their services, giving them more confidence to ship.
Characteristic picture Going through Pixabay.