Implementing Cloud-based Agile Team Development - Lessons Learned This is a Title Slide with Oracle Developer Graphic slide ideal for including a brief title, subtitle, and presenter information. Do not customize this slide with your own background. Oracle Code Translation: “Modern Cloud”    Greg Stachnick - @gstachni Sr. Principal Product Manager Oracle Cloud Development Tools June, 2017

The Cloud Changed Everything Release Frequency Quality of Software Speed of Fixing Issues Development Technologies Development Process When we started developing cloud based products we had to change many things about our approach to software development. How we deliver software How frequently we deliver the software How stable our software needs to be How fast can we upgrade the platform Which technologies we use to develop with How we develop software

Agile Methodology at Oracle Short delivery cycles Delivery of incremental solutions Focus on highest priority tasks Adapt constantly These are the main things that Agile development focuses on. Those are mapped quite nicely to what we wanted to achieve. Compare old massive waterfall FMW process to short cycles Start MVP – Minimal viable product – and iterate based on roadmap, usage, etc Some people prefer the more predictable and slower style of development but with the constant changing technology landscape. A two year release cycle can be outdated or incorrectly focused from the moment it ships

DevOps – Enabler for Agile Plan Code Build Test Release Deploy Operate Monitor DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably. Wikipedia To achieve the full DevOps solution you’ll leverage the following cloud solutions from Oracle: DevCS for the Dev part, PaaS for the deployment, Management Cloud for the operate and monitor Agile = how we organize and work as a team or as subteams DevOps = how we interact or organize with the rest of the company or IT Culture and environment Adjectives for devops are the same goals as our agile dev teams

How We Do It

Oracle Developer Cloud Service Our Team Overview Distributed team of > 170 members (developers, doc, QA, PM etc) Thousands of lines of code Scrum methodology running 2 week sprints Each sprint delivers production ready builds Uses Developer Cloud Service to manage all Development Operations (DevOps) ~170 Project Members 1000s LOCs 2 Week Sprints Oracle Developer Cloud Service

Oracle Developer Cloud Service – What’s In It Code/CI Management Version Management – Git Build Automation Ant, Maven, Gradle, npm, Grunt, Bower, Gulp, SQLcl, Shell Test Automation Selenium, JUnit, Findbugs Continuous Integration Engine Deployment Automation Team/Agile Management Issues Tracking Agile Process Management Code Review Wiki Activity stream These are the components of Developer Cloud Service. In addition we provide integration with the IDEs.

Source Management 1 Project 40 Git Repositories Component 1 Project for Developer Cloud Service Represents many Git repositories for each product component and/or sub-component Issue tracking spans project Logically separate code represents a component and has it’s own Git repository Versioned and branched independently 1 Project 40 Git Repositories Component Per Repository Task & Issue Tracker

Feature Work ~200 commits a week Master New feature/ bug fixes New features / bug fixes occur on a feature branch created by a developer Once feature / bug fixes are complete, merge request is created with target of master on component repository Default reviewers on a component repository feature branch Developer can add additional reviewers Code is reviewed Iterated over based on reviewer comments -> Approved/Rejected Merge is initiated on Approved code Every check-in that’s merged initiates a build New feature/ bug fixes Complete code Merge request to target Code review Code approved Automate build Iterate, fix & review

Preparing for Release Master Release Branch Critical Bug Fix Before a release we branch the main into a release branch. This branch is tightly managed – and only managers can approve merges into it – they do so only for critical bugs These bugs are then also merged into the master. When ready the release branch would be released to production Release Branch Critical Bug Fix Automate build Release

Code Management Tips It’s ok to have more than one git repository Leverage gitflow process – provide agility Automate code review process Default code reviewer per area Branch main for a release Lock branch to require approval for show stoppers only

Build Process Commit/push builds + 2 times a day ~50 builds a day + 2 times a day All git repositories Deploy to dev VM Automated tests Master branched every 2 weeks All git repositories Deploy to stage VM Automated tests Manual QA Candidate for production deploy ~Candidate for customers Builds (In addition to check-in builds) – Development 2 times a day an integration build is initiated Builds all Git repositories for a consistent stripe in time Build is deployed to VMs running in Oracle Cloud (Development Staging Env.) Downstream job is initiated running functional test (selenium suite tests) against env. Builds – Production Candidates Master is branched every 2 weeks and a Build is initiated Deployed to a Production Candidate VM in Oracle Cloud Selenium Tests run against Production Candidate VM in Oracle Cloud Manual QA against Production Candidate VM If all tests pass, branch may be deployed to customer production environment Development Production

Build Tips Automate notification from builds (prevent “I didn’t know it broke”) Require a test script in a build for new capabilities Regular builds lead to regular testing lead to early issue detection There is no such thing as builds overload Build executors don’t need a rest Builds for monitoring production environments runtime

The Developer’s Day Get email about new/updated task Check Sprint for open issues Git branch for feature work Work on code IDE of choice or in the cloud Commit and push changes Commit associated with specific task

The Developer’s Day Continue Runs local build on code Submit Merge Request Initiate code review cycle Reviewers notified Receive review comments Modify code, automatically starting builds When approved merge Close task

Ops Automation’s Day Merge triggers a build Unit tests are executed Build produces binaries and deploys to Maven repo If build fails – developer is notified Merging Automatically Triggers Build Builds code to produce new binaries Runs unit tests Deploys binaries to project maven repo Developers are notified of build failures Twice daily scheduled build promotes latest successful builds to staging area Failed deployment notifies developers Successful deployment notifies QA team QA verifies closed issue in staging area Automatically triggers automated selenium testing

Ops Automation’s Day Scheduled build promotes latest successful artifacts to stage area Successful deploy notifies QA team QA verify closed issues Selenium UI test run automatically Monitor runtime environments Oracle management tools Merging Automatically Triggers Build Builds code to produce new binaries Runs unit tests Deploys binaries to project maven repo Developers are notified of build failures Twice daily scheduled build promotes latest successful builds to staging area Failed deployment notifies developers Successful deployment notifies QA team QA verifies closed issue in staging area Automatically triggers automated selenium testing

Development Manager’s Day Track activity stream Issue management – assign, track new issues, Merge requests Manage sprint Track reports and progress Promote staging to production Create release branches (protected) Manage show-stoppers check-ins Issue management Assign new issues into sprints Track open issues in current sprint Merge requests Review merge requests Promote releases from staging area to production Create release branches Use “Protected Branches” feature to lock release branches to avoid unapproved merges Trigger build job to deploy release branch to pre-production staging area Automatically runs automated test suite against pre-production area Trigger build job to promote to production deployment I read the activity stream at the end of every day to review the day’s activities

Demo A day in the life of a development team This is a Section Header with Oracle Developer Graphic slide ideal for including a brief title, and optional subtitle. This slide can also be used as a Q and A slide. Oracle Code Translation: “Modern Cloud”    Do not customize this slide with your own background. A day in the life of a development team

Summary

Additional Lessons Learned Integrated Agile + DevOps is key Cloud based environment is so much simpler Team collaboration is key – everyone is a committed owner of the product

Metrics: Developer Cloud Service Team One Developer Cloud Service Project 40 git repositories, 1 binary repository 170 project members, 50 active contributors 200 commits a week 50 builds a day 21365 issues 250 wiki pages

Summary of Benefits Full traceability – issue->code change->build->deploy Faster feedback on code commits Improved team collaboration One stop shop for Agile + DevOps Accessibility of project artifacts Easy provisioning and scaling

Try Oracle Developer Cloud Service Yourself cloud.oracle.com/developer_service Tutorials Videos Whitepapers Documentation Forums

This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template. One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information.   http://my.oracle.com/site/fin/gfo/GlobalProcesses/cnt452504.pdf For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.