CI/CD Patterns and Antipatterns - Things your Pipeline Should (Not) Do

Just go with the talk.

The points that grabbed my attention were:

  • Pattern #5: Scripted pipeline - Something I will look at implementing better. My takeaway was that the example using make in the pipeline just makes it easier for developers to set up local environment, run tests, builds, etc. in the same way they are run in the pipeline.
  • Caching Container Images
  • Rules of thumb for build agent sizing
    • Developer time costs more than hardware/cloud
    • Pipeline resources should be:
      • At least as powerful as worst developer hardware
      • Ideally as powerful as the best developer hardware

Other stuff mentioned and I should read up on:

CI/CD Patterns and Antipatterns - Things your Pipeline Should (Not) Do

Codespaces, Gitpod, Devpod … what cloud and container-based IDEs can do for you

I’ve used Codespaces to write these articles.

Interesting to know of the alternatives:

When developing, troubleshooting, etc. the hardest part to debug is the environment, DEV != REF != OPS but also each developer may be running differently. Having a consistent environment helps with:

  • Collaboration
  • Debugging
  • Onboarding
  • Consistency
  • Cloud hosted allows developers to use any architecture, e.g. ARM.

Copespaces:

  • Github offering
  • VS Code ✅
  • IntelliJ ❓ - with a gateway that is currently in Beta.

Github:

  • Not linked to a specific git cloud provider.
  • But only supports a cloud provider, i.e. GitLab, GitHub, BitBucket.
  • Can use their cloud or yours.
  • Does not support .devcontainers config.
  • Uses .gitpod.yml + Dockerfile.
  • Browser extension for launching direct from GitHub.

DevPod:

  • Any git repo including local git folder.
  • VS Code ✅
  • IntelliJ ✅
  • Runs on multiple providers:
    • Local Docker, like vanilla dev containers.
    • Local VM
    • Local / On Prem K8s
    • Cloud …

Other:

  • Reference to Gitea - run your own GitHub?
  • Slides had examples of running the following in containerised environment:
    • Docker in Docker for developing containers.
    • Minikube.
    • Really running alongside the container.

CI/CD Patterns and Antipatterns - Things your Pipeline Should (Not) Do

From Java 17 to 21: A Showcase of JDK Security Enhancements

Relating to JDK security.

  • Key sizes - defaults, supported, etc. all increasing
  • Post Quantum Cryptographic Algorithms
  • SHA-1
    • Vulnerable to collision attacks
    • No longer the default
    • JDK 18 disabled SHA-1 for jar signatures where timestamp > 01/01/2019
  • 3DES - restricted since JDK 19
  • TLS-ECDH - restricted since JDK 20
  • TLS 1.2 - preferred since JDK 20
  • Java Security Manager (JSM)
    • Disabled by default since JDK 18
    • Some JAAS API need JSM so need to enable.
  • Keystore Attributes
    • Can be accessed without password since JDK 18
  • TLS/DTLS API improvements
  • Key Encryption Mechanism (KEM)
    • Secure Key Negotiation
    • New API in JDK 21
      • KeyPairGeneration
      • Encapsulate
      • Decapsulate
      • More in JDK 23
  • cacerts - since JDK 20
    • No longer uses JKS
    • Password less PKCS#12
    • Public certificates no longer encrypted
    • No longer need to change the default password
  • Tools
    • Larger key sizes by default
    • Warnings on weak algorithms

See also:

From Java 17 to 21: A Showcase of JDK Security Enhancements

Managing Kubernetes workloads: extend the platform with operators

Good introduction to operators.

  • Custom Resource Definition (CRD)
  • Operator
    • Containerised application
    • Understands your new kind
    • Creates all resources for your complex application
      • deployment
      • pvc
      • …
    • Can also do external stuff, not limited to K8S resources (like Helm)
      • Configure load balancer
      • Setup external DNS
  • Alternatives

Better than Helm? (so they say)

  • Helm relies on built-in resources
  • Templating of many yaml files - this can be hidden in the operator
  • Does not watch/monitor/update etc
  • But is good for deploying
  • Operator is good for upgrading/scaling

There is the OperatorHub.io registry.

For developing Operators see:

Managing Kubernetes workloads: extend the platform with operators

Don’t Get Burned! Secure Coding Essentials in Java to protect your applications

Good working examples in talks showing how to identify (with Snyk), presenter work for Snyk but was not pushing the product) a number of common application vulnerabilities.

  • SQL Injection
  • File path traversal - using Burp Suite,
  • XML
  • XSS - reflective and stored

Other:

  • Hashing / Encryption
    • Use the right technique for the right job
    • Use Argon2id for password hashing.
    • Use AES with GCM/CCM for encryption.
    • Need to consider how to upgrade in algorithms in the future, multiple times as standards change.
  • OpenRewrite for upgrading code for Spring Boot version.

dontgetburned - the app from the demo.

Don't Get Burned! Secure Coding Essentials in Java to protect your applications

How To Not Strangle Your Coworkers: Resolving Conflict with Collaboration

Very worthwhile talk. Need to re-watch this.

How To Not Strangle Your Coworkers: Resolving Conflict with Collaboration

From Silos to DevOps to Platform Engineering: embracing GitOps and going behind the hype

Very entertaining once you got over the accents.

Gitops:

  • Single source of truth
  • Everything as code
  • Operations through git workflows
  • Collaboration
  • Visibility
  • Security / Reliability
  • Provisioning / Deployment

See also:

Follow up - maybe read Team Topologies.

From Silos to DevOps to Platform Engineering: embracing GitOps and going behind the hype

Mayday Mark 2! More Software Lessons From Aviation Disasters

Did not cover recent Boeing problems but the presenter did mention someone else had covered these in depth.

The first talk in the series is Stories: Mayday! Software lessons from an aviation disaster.

Mayday Mark 2! More Software Lessons From Aviation Disasters