Continuous Integration - Oracle Database Objects

Continuous Integration - Oracle Database Objects

• 1.
  Oracle Database Objects ContinuousIntegration
• 2.
  ▪ Working Methods ▪Change  Pain  Risks ▪ Continuous Integration ▪ The Big Picture ▪ The Toolbox ▪ Demonstration  Feedback Agenda
• 3.
  Working Method Incremental Design Development TestingDeployment Delivery
• 4.
  Change is Permanent Incremental Design Development TestingDeployment Delivery RequirementChanges Distributed Team Manual Test Executions Integration Request for Re-Deployment
• 5.
  Change  Pain ReiterationRedeployment Revalidation
• 6.
  Pain  Risks Effort Timeto Deliver Cost
• 7.
  Continuous Integration Build anddeliver software more rapidly by eliminating pain points “Continuous Integration doesn’t get rid of bugs, but it does make them easier to find and remove” – Martin Fowler, Chief Scientist, ThoughtWorks
• 8.
  Continuous Integration Integrate atleast Daily  Continuous Integration (CI) is a development practice  Each Check-in is verified by an automated build  Integrating regularly helps to detect errors quickly Reduces Issues with Distributed Team Environment Reduces Integration Issues
• 9.
  Continuous Integration Solve ProblemsQuickly  No more long waiting period for results  Increase visibility which enables greater communication  Spend less time debugging and more time adding features  Proceed in the confidence you’re building on a solid foundation  Stop waiting to find out if your code’s going to work Reduces Time/Effort consumption by Manual Test Executions Reduces Time/Effort involved in Redeployment
• 10.
  Continuous Integration Principles andPractices The Practices How to do it ?  Maintain a single source repository  Automate the build  Make your build self-testing  Every commit should build on an integration machine  Test in a clone of the production environment  Make it easy for anyone to get the latest executable  Everyone can see what’s happening  Automate deployment
• 11.
  Overview Commit Code Version Control CIServer Feedback Mechanism Feedback Mechanism Development Team The Big Picture
• 12.
  POLL ANALYZE RESULTS RESULTS CI ServerVersionControl Feedback Mechanism Feedback Mechanism CommitChanges CommitChanges BUILD SUCCESS BUILD TEST DEPLOY The Big Picture BUILD FAILURE
• 13.
  CI Server Build& Deploy Code Version Control Unit Test Framework Code Quality The Toolbox
• 14.
  Why Jenkins?  Ledby Developers for Developers  Governance and Community  Stability  Primary platform for Plug-ins  Cloud-Enabled Jenkins, a continuous build tool, enables teams to focus on their work by automating the build, artifact management and deployment process
• 15.
  Maven helps adeveloper to comprehend the complete state of a development effort in the shortest period of time Why Maven?  Making the build process easy  Providing a uniform build system  Controls the entire Build, Test & Deployment phase of CI Setup  Change Log Documents  Unit Test Reports  Keep your test source code separate  Easy ways to update  Easy way to install new plugins
• 16.
  Four Steps forusing UTPLSQL  Install UTPLSQL  Identify the test cases for a program  Build a Test Package  Run your test Why utPLSQL? utPLSQL is a unit testing framework for programmers using Oracle's PL/SQL language and allows the automated testing of packages, functions and procedures
• 17.
  CommentsStandards Design Complexity BugsCoverage Duplication Why SonarQube Code Analysers  Reporting Tools  Defect Hunting Modules  Time Machine  Extended Functionality by Plug-in(s) “One-Shop-Stop for Source Code Quality Management”
• 18.
   Continuous Integration[HUDSON]  Automated Polling [HUDSON  SVN]  Automated Build [HUDSON  SVN  MAVEN]  Automated Test [HUDSON  SVN  MAVEN  UTPLSQL]  Automated Code Analysis [HUDSON  SVN  MAVEN  UTPLSQL  SONAR] Demonstration JENKINS  SVN  MAVEN  UTPLSQL  SONAR Summary
• 19.
  Prabhu Ramasamy prabhuramasamy.cbe@gmail.com