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

2. 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.

3. 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.

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

5. 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

6. Affinity Diagram - before Process Change
To Add

7. Topology
Topology

8. 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

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

10. 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.

11. 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.

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

13. 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.

14. 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

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

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

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

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

19. Affinity Diagram - after Process Change

20. 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.

21. 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

22. 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

23. 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

24. Publication