Best Practices for Enterprise Continuous Delivery of Oracle Fusion Middleware 12c
Download as PPTX, PDF1 like1,287 views
The document discusses the challenges and best practices of implementing continuous delivery in large organizations, highlighting the integration of legacy applications and new processes. It emphasizes the importance of model-driven infrastructure, automated deployments, and version control to streamline development and operations. Additionally, it outlines potential organizational challenges and provides recommendations for code quality and deployment procedures in Oracle environments.
Best Practices for Enterprise Continuous Delivery of Oracle Fusion Middleware 12c
- 2. 2
- 3. OGh Oracle Fusion Middleware Experience 2016 bij FIGI Zeist Maarten Smeets and Robbrecht van Amerongen, 16-02-2016
- 4. 4 Who are we? • Maarten Smeets – Senior Integration Consultant – Experience with Oracle SOA Suite since 2007 – Well certified (SOA, BPM, Java, SQL, PL/SQL) – Author of more than 100 blog articles https://nl.linkedin.com/in/smeetsm http://javaoraclesoa.blogspot.com [email protected] • Robbrecht van Amerongen – Manager Continuous Delivery & Security – Initiator of the Red Expert Alliance – Agile Master https://www.linkedin.com/in/robbrecht 0641010286 [email protected]
- 5. 5
- 6. 6
- 8. 8 How does it feel
- 9. 9 Implementation of Continuous Delivery in large Organizations is a Challenge
- 10. You have to - Work with a heritage of legacy applications - Cope with existing processes, governance and procedures - Work with “old” and the “new” world next to each other - Integrate the old and the new world - Operate new technology with old processes - Operate new processes with old tools - Cope with (sudden) mandatory surprise requirements - Operate with a rigorous compliancy model - Cope with the “that is just the way it works” culture… - Other weird surprises…..
- 11. 11
- 12. Triggering Execute Validate Complete manual Scripted Automatic Continuous Manual Continuous
- 13. https://technology.amis.nl/2015/04/01/continuous-delivery-maturity-model-nederlandse-versie/ Prioritized work Infrastructure as code Cross functional teams Version control database changes Fully automated deployments Automated testing Test coverage reporting
- 14. 14 “there can only be one” Just because you can script anything with Jenkins does not mean you have to
- 15. 16 Tool fit for the job, suitable for your organization and FMW technology Acceptatie Bouw Team Systeem 2 Bouw team Systeem 1 Bouw Team Systeem n SCM Automated Provisioning omgeving Build Domain Specific Language Continuous Integration QA Automated deployments / testing Ontwikkel OS and Middleware ONTW Test OS and Middleware Integratie OS and Middleware ACCEPT OS and Middleware Productie OS and Middleware PROD ArtifactRepository Provision Deploy Build
- 16. 17 Model driven • Model driven infrastructure (including configuration management) • Model driven build (templates) • Model driven deployments (labeling and pipelines) • Model driven testing • Model driven monitoring / alerting
- 17. Example: Overview of MyST Strong Governance & Consistency Platform Blueprints • Define standard topology • Ensure consistency across all environments • EDG Templates provided out of the box Platform Models • Map Blueprint to Specific Environment • Defines environment specific details Blueprints & Models version controlled • Control promotion to new environments • Easy to rollback to previous environment Fully automated provision • Provision new environments in minutes Model Driven Design
- 18. 20 Release train
- 19. 23 Multiple teams Challenges • Working on the same components (branching and merging) • Sharing target environments (or not sharing and late integration) • Different project phases (e.g. live and not live) on the same codebase • Use Component or feature teams? • Keeping development standards and process streamlined (avoid isles)
- 21. 26 DevOps
- 22. 28 Organizational Challenges • Responsibilities for Continuous Delivery in a Silo-organization • Project structured in Components. Feature teams vs. Component teams • Localized Optimization and no focus on over all time to market • Quality Build in the process • Technical debt due to project deadlines • Can you grow your organization according to the CD maturity model.
- 23. 29 Technical best practices Automate the stack InfraPlatformSoftware Hardware Application server / Database Configuration Application Operating System Virtualization can cost performance Mind licensing issues! Backups in SOA are hard Use a standard well supported OS such as OEL or RHEL Practice creating new environments (when it hurts do it more often) All configuration should be scripted in a way everyone understands Automate quality checks. Use a deployment pipeline
- 25. 31 Hotfix procedure Development Functional Test User Acceptance Production A hotfix for release 1 - Cannot use the regular pipeline - Requires updates of next releases - Should be tested where? Release 3 Release 3 Release 2 Release 1 Less releases underway, less work to hotfix. P = D – 1 ! Solution: - A specific pipeline to deploy a hotfix - Hotfix environment running on the production release or acceptance and production running the same release
- 26. 32 Version control and tracing Atlassian stack sample FishEye visualizes and reports on version control activity You can require mentioning an issue number when committing with commit hooks
- 27. 33 Version control and tracing
- 28. 34 Challenges building with Oracle and Maven / ANT • Scripts from hell – That one person who knows how it works – Tight coupling between scripts and deployment tooling (migration will be painful) • The incremental database and Maven – Cultural issues: it has to be done with SQLPlus – Technical issues: I want to be able to rebuild my database from scratch to create a new environment. I want to combine the increments of several sprints • Maven only for 12c+ – Maven for all artifact types? • 12.2.1 libraries not yet in Oracle Maven public repository Rerunnable code (within sprintrelease)! Store database code per sprintrelease. Store the incremental set of sprintreleases to recreate an environment. KISS. Harder than you think! Standardize. Reduce the number of different products and component types Keep all your code in the artifact repository. A release is just a list of artifacts
- 29. 36 Code quality of ADF
- 31. 38 SOA code quality • SonarQube ojaudit plugin available, but no SOA audit rule-set (requires Java coding) • AIA has a Code Compliancy Inspector (CCI) https://docs.oracle.com/cd/E28280_01/doc.1111/e15754/codecomplianceinsp.htm#OERIN877 https://github.com/wvanderdeijl/oracle-cci-sonarqube • Have payload validation turned on in development! Do we have a set of SOA development standards we can agree on?
- 32. 39 Deployment SOA Loose coupling • Dependencies create complexity – Dependency loops – Installation ordering in build code required – Can cause server start issues Avoid direct service artifact dependencies! • Use MDS for shared artifacts • Do not use SOA-Direct Service A Service B Cyclic dependency https://blogs.oracle.com/aia/entry/aia_11g_best_practices_for_dec
- 33. 40 Practices
- 34. 41 Best practices (1/2) • No big bang / Continuous Delivery • Small number of component types using a consistent release process • Release large deployable components • Regular releases; when it hurts do it more often • Do not hold the release until every stakeholder agrees • Silent deployment / feature toggles
- 35. 42 Best and worst practices • Working v.s. Perfect (focus on throughput) • Fix the build pipeline first • Reserve a process for hotfix (incidental) • Be practical, not a fundamentalist CD • One size fits all tool does not exist
- 37. 44
Editor's Notes
- #12: Vragen aan de zaal wat ze gebruiken Wie gebruikt versiebeheer Wie jenkins / wie git Wie gebruikt build engine Dagelijkse build Ook voor de database Wie gebruikt artifact store Wie heeft er ook nog een apart opleverproces Wie gebruikt platform provisioning Afconfigureren Wie gebruikt er deployment automation Tot aan producite
- #17: This is a familiar image to MN
- #19: Rubicon Red Key Points How to build and provision similar environments in the cloud and in the data center. Need to ensure that code that runs in the cloud works equally well when moved to Production (on-premise). Eliminate configuration drift (http://blog.rubiconred.com/eliminating-configuration-drift-for-oracle-soa-and-bpm-projects/)
- #21: The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases) It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release). If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content. From: http://leadingagileteams.com/tag/agile-release-train/
- #30: Maps to cloud layers, IAAS, PAAS, SAAS
- #33: Visualize and report on activity and search for commits, files, revisions, or teammates across SVN, Git, Mercurial, CVS and Perforce.
- #35: Changes in artifact structure are troublesome
- #41: “ worst” practices.. ?
- #44: If Oracle suggests a certain way of doing things, adhere to it! Deviations will cause future pain. Examples: enterprise deployment guide, project structure. Reduce the number of different technical components such as custom JARs deployed on the application server, custom property files, specific technical feature. They require effort to get automated or effort/error in manual execution, causes difficulties in setting up a new environment. The CD code should be as simple as possible. This code also requires maintenance! The one person who does all the CD things. No, CD is a joined effort! The PO can choose quality but usually he/she doesn’t. Shared vision/direction. This is harder when there are more stakeholders, more people with strong opinions (senior developers, architects) Focus on quality (robustness of code), logging, monitoring, code quality, testing.