Deployment Strategies & DevOps for Banking Apps PDF

Deployment Deployment Sucks Many times, I have experienced the situation – it’s time to get QA started on our code. Or time to push our code to production. You copy files over and … nothing works. Or, maybe worse, most everything works, but something doesn’t. Every eye is on you, you are sweatin...

Deployment Deployment Sucks Many times, I have experienced the situation – it’s time to get QA started on our code. Or time to push our code to production. You copy files over and … nothing works. Or, maybe worse, most everything works, but something doesn’t. Every eye is on you, you are sweating trying to figure out why… Servers Suck You have a lot of machines in your server rack. They each have free space and free CPU, but putting more than one application on the server is difficult and dangerous. They might depend on specific versions of libraries. Or web servers. Or applications. It would be really nice if I could safely deploy multiple applications to multiple servers. Virtual Machines can solve this… What if we create a VM for every server. Each VM emulates the CPU, has an operating system installed and is completely isolated from the rest of the system. This works but is incredibly inefficient. What if every app is running x86 Linux? Advantages of Virtualization Minimize hardware costs Multiple virtual servers on one physical hardware Easily move VMs to other data centers Provide disaster recovery, aid hardware maintenance Consolidate idle workloads. Usage is bursty and asynchronous. Increase device utilization Easier automation. Simplified provisioning/administration of hardware and software Scalability and Flexibility. Multiple Operating Systems Disadvantages of Virtualization Each VM requires an operating system Each OS requires a license Each OS has its own compute and storage overhead Needs maintenance, updates VM tax Solution: Containers Run many apps in the same virtual machine These apps share the OS and its overhead But these apps can’t interfere with each other Can’t access each other’s resources without explicit permission Like apartments in a complex Popular container solutions: Docker Kubernetes Containers Multiple containers run on one operating system on a virtual/physical machine All containers share the operating system Containers are isolated: cannot interfere with each other Own file system/data, own networking: Portable Containers Containers have all the good properties of VMs Come complete with all files and data that you need to run Multiple copies can be run on the same machine or different machine: scalable Same image can run on a personal machine, in a data center or in a cloud Operating system resources can be restricted or unrestricted as designed at container build time Isolation Can be stopped, saved and moved to another machine for later run DevOps DevOps 7C’s of DevOps Continuous Development Planning and coding the software Version Control Systems (Git) Continuous Integration Developers commit changes Every commit is built Unit Testing Integration Testing Code Review Packaging 7C’s of DevOps Continuous Testing Developed software is continuously tested for bugs Use automated testing tools TestNG, JUnit, Selenium Allow QAs to test multiple code-bases thoroughly in parallel Docker containers are used to simulate test environment. Continuous Deployment Code is deployed to production servers Containerization helps produce consistency across development, testing and production environments Continuous Monitoring Information about the use of the software is recorded Used to identify trends and problem areas Tools Production-identical environments for development Source control and collaborative coding Continuous Delivery Tools that automatically apply your tests to development branches Give you the option to push to main when branch builds are successful. Continuous feedback in real-time chat alerts Automated Testing Increase software quality and reduce risk early and often Cover several areas: UI testing, security scanning, load testing Reports and trend graphs that help identify risky areas Automated deployment Create utility methods or scripts for deployment to different environments. Standardize task lists for deployments Reduce difference between environments Operate and Observe Incident, change and problem tracking Application and server performance monitoring Open-Source Git (Version Control) Docker (Continuous Deployment) Jenkins (Continuous Integration and Continuous Delivery) Selenium (Web apps), Bamboo (Server) (Continuous Testing) Jira (Continuous Development and Feedback) Prometheus (Continuous Monitoring) Opsgenie (Continuous Operation)  Testing How do we make sure that we get it right? The biggest takeaway You cannot wait until the last minute to think about quality You have to “bake it in” – plan for, design for, code for and test for quality. It isn’t just a development issue, either. Quality comes from every part of the organization. In-class Exercise You are working as a quality assurance (QA) engineer for a team building a banking app. One feature of the app is a "Transfer Money" function, which allows users to transfer funds between their own accounts or to another user's account. The requirements for the function are: 1. The source account must have sufficient funds for the transfer. 2. The transfer amount must be between $1 and $10,000 (inclusive). 3. Both the source and destination accounts must exist and be active. Types of issues Specification Issues Coding Issues Documentation Issues Systems Issues (capacity, performance, recovery, dependencies) Security Issues Specification Issues The specification could be missing something. This happens most often for unusual or rarely thought about circumstances. The specification could be impossible to implement. The specification could be misinterpreted. The specification could be outdated. How do you prevent this? Active reading by systems architects is the best defense here. Ask a lot of “what if” questions. Try to guess what could be missing by asking about and fully understanding the problem domain. As you actively read the specification, try to imagine what the code structure might look like. What types of algorithms you might choose for complex problems. Coding Issues We are all experienced with coding issues, but let’s break them down a bit. One thing that you have to be careful about – bugs will happen. You can’t be too hard on yourself – it will happen even to the best of us on our best days. You can’t be too easy on yourself – otherwise you don’t learn. Fault Types Algorithmic fault – we chose an algorithm that doesn’t scale or doesn’t solve the problem every time UI/Code mismatch – you wire the Login button up to Log Out, a control is disabled that you need, etc. Logic Bugs – off by one, update the wrong variable, wrong operation Out Of Bounds – negative or >100%, human age 120 Fault Types Memory Errors - reuse freed memory, access out of bounds Syntax errors – for (i=0;i