The Software Development Lifecycle for Product Managers

Build, Testing and Deployment: Technical Knowhow for Product Managers

Welcome to part seven of a series of articles covering the technical knowledge that every Product Manager ought to know. Today I’m going to be talking about The Software Development Lifeycle, with a special focus on Build, Testing and Deployment and what DevOps means for PMs.

If you’d like to learn why I think this knowledge is important, then head back to my article where I discussed WHY it’s important to work on technical skills in Product Management.

And don’t forget to subscribe to email updates if you want to be notified when the next article is published!

Build Stage

According to a traditional waterfall model, the build or implementation stage begins after analysis and design, and before testing, deployment and maintenance. The build stage is where the development team transforms the product requirements and design into actual code.

However, the seperation between these phases is not always so distinct. During the build process, there may be deviations to planning according to unknowns surfaced during development.

There can also be a more iterative approach, where build itself is also a form of prototyping, validating a hypothesis developed during analysis and design, that will call for further analysis and design. Or an incremental approach, where each release covers ‘slices’ of a feature.

More typically, product teams will use a combination of these different working styles, depending on the scope and complexity of the project that they are working on.

As a product manager, you need to work closely with the development team to ensure that the code meets the product requirements and is feasible within the budget and timeline constraints. During this stage, you’ll probably be called upon to make quick decisions based on tradeoffs or previously undiscovered complexities that the development team surface during the build process.

Testing

During the testing phase, the development team verifies the functionality, quality, and reliability of the software product. Testing might involve manual testing or the use of automated testing tools.

Testing might be carried out by the same development team that worked on the original code (although ideally some kind of peer review exists at a minimum), but testing can also be carried out by QA developers specialised in quality checks, and the product manager themselves. Testing can also form a kind of documentation as to how the code is to be used.

Some of the common types of testing that might be used:

• Acceptance testing — testing a feature or application as a whole against the business requirements/user stories
• Integration testing — validating that different components function together
• Unit testing — testing individual units/components in isolation to check they perform as expected. Really important because they give short feedback loops, and help developers detect errors as early as possible.
• Regression testing — verifying that the changes made to the software application do not negatively impact its existing functionality, by retesting use cases on both affected and non-affected parts of the application with the same test cases and data that were used previously.
• Performance testing — evaluating how the application might work in different real-life load scenarios
• Stress testing — a non-functional testing type to see how much strain a system can take before it fails
• Usability testing — validating how easy the application is for a customer or user to use

Having a good test coverage allows developers easily refactor code (i.e., rewrite existing code). Without test coverage, refactoring may introduce errors, which makes developers less likely to refactor the code, which makes the code rot.

Some teams may adopt test-driven development, where tests cases are written based on requirements before the software is developed. You can read more about test-driven development via the reading list at the end of the article.

What is Continuous Testing?

Continuous Testing is a process of integrating automated testing into every stage of the development cycle, to create quick feedback loops and make sure that issues are spotted as quickly as possible. Continuous testing generally works by using automated tools to run quality assurance scripts, reducing the need for manual human intervention until an actual problem is surfaced.

Deployment

After testing, the product can be deployed to the next environment.

The environment on which the user/customer interacts with the application is called the ‘production environment’ or ‘prod’ for short. However, there is a sequence of environments through which the application is deployed. The deployment pipeline is the process of getting a code change to production.

Commonly the pipeline consists of the development environment, test and staging or UAT environment, but it varies according to the needs and maturity of an organisation.

The benefit of testing the application and checking it works in each environment before deploying to the next is a higher level of confidence in the code.

Usually ‘later-stage’ environments will closer reflect the actual data available on production, and allow QA, product and business to test scenarios closer to the ones a user will encounter. Where a UAT or staging environment is maintained with realistic data, it can offer an additional chance for the product manager to test the product with stakeholders or customers before it is released on the production environment.

CI/CD

CI/CD stands for Continuous Integration/Continuous Delivery OR Continuous Deployment. It is a set of practices around software development.

In a traditional model, where development is done in a linear sequence of steps, each step is completed before moving on to the next. This could allow issues to go undetected for longer periods of time, and led to less frequent release cycles as every stage had to be fully completed before the next started.

CI/CD aimed to address some of these issues by automating and streamlining parts of the development process.

Continuous Integration

Continuous Integration refers to the practice of frequently integrating code changes into a shared repository, where automated builds and tests are run to ensure that the changes do not break the software application. So when one developer is writing one piece of code, and another on a different part of the application, they can integrate both changes together in the source repository and check that the code works. This helps identify issues and defects early in the development cycle, allowing developers to address them quickly and efficiently.

Continuous Delivery

Continuous delivery means that we’re always in a state where we can (manually) deploy — imagine a human pressing a “deploy button”. This also allows to bundle features and release them together. In continuous deployment, each changed is automatically deployed to PROD.

Continuous Deployment

Continuous Deployment refers to the practice of automating the deployment of code changes to production, once they have been tested and approved. This helps ensure that the software application is always up-to-date and running smoothly, and reduces the risk of introducing issues or defects when deploying new code changes.

Some companies choose not to adopt continuous deployment; continuous changes to the production environment that a user is actually interacting with may have downsides, too. A two-week (or longer) release cycle may better allow the product team to notify other teams and customers of upcoming changes and monitor performance and feedback on production environments.

Why should a team adopt CI/CD practices?

CI/CD offers the potential benefits:

• Shorter testing and release cycles
• Easier rollback if needed
• Improved quality from fewer bugs/issues on production
• Potential for cost improvement from automation

However, it may also present the following risks

• Speed of changes may not be suitable for every team; Changes rolled out at a speed that customer support may not be prepared for; there can be advantages to a fixed tempo of releases, communicated well in advance to customer-facing teams
• Speed of changes may not be suitable for every industry; highly-regulated industries may not be suited for processes that release changes so frequently to production
• Automation can increase complexity of proceses; automation is not foolproof and also requires monitoring

Therefore whether ought to apply some or all CI/CD practices depends heavily on the needs of their own team, users and company.

Want to learn more about DevOps best practices?

If you’re a PM wanting to learn more about DevOps best practices and how they actually affect the running of a business, I strongly recommend “The Phoenix Project”. I first read it before I even worked in a product role, when it was just a vaguely interesting stand-alone novel about an IT project gone wild and annoying co-workers. Re-reading with a few more years in tech under by belt, I’m pretty impressed by the way in which the authors manage to evangelise devops best practices in the guise of a novel. The book makes what can be a pretty dry topic and makes it interesting for the Average Joe PM. Like I said, I had minimal technical knowledge when I first read the book but I still found it interesting. It’s not perfect, but it’s a captivating entry point.

Want to improve your technical knowledge? I’ll be sharing articles every week. Here are the ones published so far:

1. What Is The Internet?
2. Tech Stacks and Programming Languages
3. Cloud Computing
4. APIs
5. Databases
6. Introduction to Software Architecture
7. Software Development Lifecycle ← You are here!

Don’t forget to subscribe for email notifications to be updated when the next article in the series goes live!

Further Reading

• What is the Software Development Lifecycle — by softwaretestinghelp (article)
• The Difference between Waterfall Model and Incremental Model — by geeksforgeeks (article)
• The Iterative Model — by artoftesting (article)
• What is Software Testing and How Does It Work? — by IBM (article)
• Continuous testing — by IBM (article)
• What is CI/CD? — by freecodecamp (article)
• The Product Manager’s Guide to Continuous Delivery and DevOps — by MindTheProduct (article)
• The Pros and Cons of CI/CD Pipelines — by techtarget (article)
• The Phoenix Project — by Gene Kim, Kevin Behr and George Spafford (book)
• Test-driven development — by wikipedia (article)