A Case Study: Automated Continuous Software Engineering Cycle (ACSEC) 演讲者: Xin Bai 职位: Senior Software Engineer 来自公司: The Microsoft Corporation

Abstract There are many different processes and methods during a software development and engineering. Automated continuous software engineering is a further extension to some of the existing popular methods, such as, continuous integration as well as continuous delivery. It focuses on the reversed direction from customer to engineering and emphases on the whole life cycle of the software as a product. It completes the cycle of software development and engineering along with reporting and customer feedback. The automation implemented in each phase makes it the most effective and productive process for the software development and engineering. It fulfils the goal from a different perspective for the customers to verify the system health and further correct the system issues automatically. Here, we present a study case to demonstrate how we leverage this process to solve our software engineering issue and support the product life cycle.

Introduction From time to time, many software development teams across industry wonder which process or methods to leverage to best fit their development and engineering needs. That is mainly because that different teams had developed different systems and applications, such as, Microsoft Windows apps, web site apps, and WCF (Windows Communication Framework) services, which may result in different engineering approach for different teams. Also, sometimes, it is because that people are so used to be with a traditional method of developing software, such as, waterfall model, to work on the software development and engineering.

Problem Statement Environment Contention Environment Health One Direction of CI/CD Slow Development Cycle Quality Issues Not Automated Process Disconnection between Engineering & Support

Key to succeed Team work Open to accept change Automation is priority Use SSDT for SQL Use wix project for deployment Use Cloud for Onebox and Multibox Use MS build

Affinity Diagram - before Process Change To Add

Topology Topology

Practice 1 Automatic Provisioning Create templates in Genesis – one time work. Call Genesis API to provision OneBox or MultiBox automatically. Provisioning is kicked off after a successful build is detected only. Move to cloud

Practice 2 Continuous Software Engineering Life Cycle Continuous Build Gated Build Unit Test Suite BVT & Code Coverage Standard Reporting

Practice 3 Continuous Software Engineering Life Cycle Continuous Deployment Deploy the build onto either OneBox or MultiBox. Right topology - Deploy onto an existing environment or new provisioned environment. Right hardware Deployment is kicked off after a successful provisioning only.

Practice 4 Continuous Software Engineering Life Cycle Continuous Integration Continuously checks for new builds and local builds, provisions, deploys, and executes tests Tool - Genesis OneBox Template - all components are on one machine MultiBox Template – simulate communications, firewall configurations, etc. Genesis API is integrated into deployment and TCF test solution.

Practice 5 Continuous Software Engineering Life Cycle xVT Leverage VS for testing – unit test and console application Execute xVT automatically anywhere after deployment Scheduled Email Notification Ops gets the errors from notification and enters them into their ticket system

Practice 6 Continuous Software Engineering Life Cycle Continuous Regression What is the right regression Beyond BVT UAT Continuous Correction Automated bug logging. Automated system recovery. Bring back into engineering cycle.

Practice 7 Continuous Software Engineering Life Cycle Continuous Monitoring and Reporting Infrastructure Level Monitoring What to monitor? Comprehensive system monitoring. Telemetry Monitoring and Reporting is more Important

Practice 8 Continuous Software Engineering Life Cycle Continuous Notification Ops gets the errors from notification and enters them into their ticket system Email notice Disaster Recovery

Challenge 1: Continuous TiP & Trouble Shooting Automatically grab production data Automatically re-pro production failure in test environment Help production issue trouble shooting

Challenge 2: Continuous Customer Feedback Automatically collect customer feedback in an efficient way It impacts the engineering cycle most

Challenge 3: Continuous Application Level Correction Automatically correct the apps in an efficient way It optimizes the engineering cycle

Affinity Diagram - after Process Change

Takeaways Build a foundation for Automatic Provisioning in cloud. Leverage automated gated build process for each check-in or per request. Full deployment is basic and delta deployment is practical. BVTs for integration is the key. Create a proper suite of xVT (EVT, IVT, and BVT). Execute a proper regression. Infrastructure level of auto-correction is doable. Telemetry must be part of design. Various reporting and dashboard helps with customers.

Lesson Learned Disconnection between Engineering & Support so that TIP is a challenge. Business UAT bottleneck – Customer feedback is slow. Automated application level correction is far from reality. Others Complexity of BVTs Infrastructure Instability Quality Challenge

ROI Reduced full release of a new lane of system from 6 months to 1 month More confident to the system quality More agile due to continuous work Robust system due to automation in each phase of the development Scalability Released more frequently

Future Azure VMs for provisioning Automated bug opening in the ticket system while getting the errors from xVT notification Automated error correction while getting the errors from xVT notification Telemetry to get real time production metrics Machine learning to categorize the exceptions for troubleshooting. Test in production (TiP) Application level of correction

Publication http://www.worldacademyofscience.org/worldcomp15/ws/conferences/ike15 http://www.clocate.com/article/A-Case-Study-Automated-Continuous-Software-Engineering-Cycle/360/