Page Comparison

...

• Continuous Integration
  
  • CI server detects code is committed, verifies code and runs tests
  • Versioned Artifacts are also created for further validation and usage in downstream deployments
    • Confirms that the artifacts deployed are the ones tested
    • Reused without continual recreation
    • Traceability back to the commit
  • 3 questions from Jez Humble on whether you're really doing it
    • Do you check in to mainline once per day?
      • Even if you are using short-lived branches, integrate frequently
    • Do you have a suite of tests to validation your changes?
    • When the build it broken, is it the #1 priority of the team to fix it?
  • Repo
    • Since repo and single CI build for all microservices
      • requires lock-step releases
      • Ok for early stage and short-period of time
      • Cycle time impacted - speed of moving a single change to being live
      • Ownership issues
    • Single repo with separate CI builds mapping to different parts of the source tree
      • Better than the above
      • Can get into the habit of slipping changes that couple services together.
    • Separate repo with separate CI builds for each microservice
      • Faster development
      • Clearer ownership
      • More difficult to make changes across repos - can be easier via command-line scripts
• Continuous Delivery
  • Treat each check-in as a release candidate, getting constant feedback on its production readiness
  • Build pipeline
    • One stage for faster tests and another stage for slower tests
    • Feel more confident about the change as it goes through the pipeline
    • Fast tests → Slow tests → User acceptance tests → Performance tests → Production
• One microservice per build
  • Is the goal
  • However, while service boundaries are still being defined, a single build for all services reduces the cost of cross-service changes
• Deployable Artifacts
  • Platform-specific
  • OS-specific
  • Images
• Environments for each pipeline stage and different deployments
  • different collection of configurations and hosts
  • Service configuration
    • Keep configuration decoupled from artifacts
    • Or use a dedicated config system
• Service to host mapping
  • Multiple services per host
    • Coupling, even with Application Containers
  • Single service per host
    • Monitoring and remediation much easier
    • Isolation of failure
    • Independent scaling
    • Automation mitigates amount of overhead
• Virtualization
  • Vagrant - can be taxing on a developer machine when running a lot of VMs at once
  • Linux Containers
  • Docker - Vagrant can host a Docker instance