Author Archives: Jeanne Boyarsky

[oracle code one] maven bof

Posted on by
Reply

For more blog posts, see The Oracle Code One table of contents

Discussion based. Key points:

  • 3.6.2 – some people were able to reduce memory consumption a lot. Four times less
  • 3.6.2 – environment variables in toolchain, not just settings.
  • Future: specify if want to fail on warnings (default to warn on warn)
  • CI: clean out workspace vs maven clean. Maven clean avoids pulling code again or if have local repo in workspace
  • Latest maven compiler will remove class files if sees change. Then recompiles
  • Some projects call plugins without understanding what do. Some can be unused code.
  • ”90% issues are people adding stuff don’t need”
  • Fabric 8 plugin – can generate and deploy docker images
  • Visual tool to show the build plan https://github.com/jcgay/buildplan-maven-plugin

My take

Any session where I have “homework” (something to try) is a good one in my mind!

[2019 oracle code one] maven stories

Posted on by
Reply

Broken Built Tools & Bad Habits: The Maven Stories

Speaker: Robert Schoite @rfschoite

For more blog posts, see The Oracle Code One table of contents


General

  • Instructions change over time and following practices from prior generations can get you in trouble.
  • Advice from Maven 1 and 2, may not apply to Maven 3
  • When learn new things – analyze, google/stack overflow, ask colleagues
  • When things fail – do three things when learning. Or can fix, create workarounds.
  • Workarounds tend to turn into a pattern
  • CI server is the neutral judge. Counter to “it works on my machine”
  • Apache tests latest Maven 3.0, 3.2, 2.3, 3.5 and 3.6 with java 7. And 3.6.1 with Java 7, 8, 11, 12 and 13 early access. Test on Ubunto and Windows

Why it works on your machine but not server

  • Changed code
  • OS – ex: Windows not case sensitive
  • JDK
  • Version of Maven
  • Files – regular files/directories
  • Properties – system/environment

Options to troubleshoot

  • -v version of Maven
  • -V version info and run build. Good for running on CI server
  • -e execution error messages
  • -X execution debug info

Local repo

  • No TTL (time-to-live)
  • Maven 2 – dumb cache
  • Maven 3: _remote.repositories – verify cached artifacts still exist
  • Designed for single user. CI server can be multi user and corrupt files due to concurrent writes/reads
  • Takarai Concurrent Local Repository – adds file locking to repo
  • Checksums not verified by default. -C is for strict checksums to fail if don’t match or -c for lax checksums to warn if don’t match. Shouldn’t be a problem now since binary repos have checksums. In Maven 4, will probably turn on by default.
  • Maven 2 and 3 share directory. In future, might separate SNAPSHOTS or by different remote repos

Multi modules

  • In Maven 2, not aware of reactor. Dependencies had to exist in local repo
  • Maven 3 is reactor aware so shouldn’t need install anymore. [for this scenario]
  • Can use installAtEnd/deployAtEnd experimental feature to wait until the last module runs

Flow

  • Locally run mvn verify
  • On CI Server, run mvn deploy. (hard to write without install so that is fine too)
  • This technique means all SNAPSHOTS are served by repo manager

Performance

  • Aim for clean Maaven output
  • Don’t write to System out/error
  • Don’t log during testing loglevel = off
  • Can set Maven flag to quiet if needed

Files

  • Replacing files is a waste
  • Most plugins can handle incremental execution
  • Avoid maven clean because forced rework
  • He wrote a plugin to nag you about using clean and install

Properties

  • Don’t change version of Java or a dependency on the command line

Versions

  • Maven 3.5.0 comes with CI friendly placeholders. Can specify revision, sha1 or changelist in version #. Ex 3.1.0-JIRA101-SNAPSHOT
  • Need relative path or GAV when building. Dependencies must use GAV
  • Maven 3.7 will probably require Java 8+

My take

This was good. Assuming you are familiar with Maven, there was a lot of info covered quickly but not hard to understand. If you don’t know Maven, I suspect this would have gone over your head. I learned a few new things so I’m happy.

[2019 oracle code one] inspecting in CD pipelines

Posted on by
Reply

Silence of the Lambs: Inspecting Source Code and Binaries in Continuous Delivery Pipelines

Speaker: Michael Huettermann @Huettermann

For more blog posts, see The Oracle Code One table of contents


General

  • More than one solution.
  • First “DevOps” book – Adam Smith – Wealth of Nations – talks about division of labor
  • Holistic/shared goals/processes/tools
  • Cycle time – across functions, create own definition

Pipelines/cycle time

  • Start with value stream map
  • Identify areas for improvements
  • Every chain has a bottleneck.
  • Consider theory of constraints. Fixing one bottleneck will expose another.
  • Consider as doughnuts, not tubes. Want feedback.
  • Glue together existing tools.
  • Identify stages and quality gates
  • Automate
  • ex: continuous build, dev build, RC build, GA build
  • “Pushing around binaries is a vintage approach” – should add context info

Many tools

  • Binary repo (Nexus, Artifactory)
  • Containerized infrastructure
  • Cloud enabled setup
  • Continuous Inspection (SonarQube for code, Twistlock for Docker)
  • Supporting/cross cutting tools
  • Middleware (Tomcat, JBoss)
  • Functional monitoring (ELK)
  • Automation engine: (Jenkins)

My take

The images were a good case study. While I would have rather have seen a live demo than a video, it was a video the speaker made so pretty equivalent. And he narrated it well.