Software that moves money has to be right before it ships and visible once it is running. A bug that reaches production can charge customers twice or leave a ledger out of balance, and a problem you cannot see is a problem you cannot fix. This final module covers the habits that keep a fintech system trustworthy over time: testing it, watching it, and releasing changes to it safely.
You'll start with testing, using the testing pyramid to decide how many unit, integration and end-to-end tests a system needs. Then you'll learn observability: how logs, metrics and traces together show what a distributed system is doing in production. After that you'll see how a CI/CD pipeline builds, tests and delivers every change automatically, and finish with deployment strategies such as blue-green, canary and rolling releases, which limit the damage when a change goes wrong.
Remember that a passing test suite tells you the code does what you expected, while monitoring tells you what is actually happening for real customers. In financial software you want both, plus a fast way to roll back. You've now reached the end of the lessons, so finish with the Projects to put the modules into practice.
An introduction to the testing pyramid and how unit, integration and end-to-end tests fit together, so you know where to spend your testing effort.
What logs, metrics and traces each tell you, and how they combine to make a system of many services understandable in production.
How blue-green, canary and rolling deployments differ, and how each one reduces the risk of releasing a change to production.