Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Continuous Integration and Delivery using TeamCity and Jenkins

270 Aufrufe

Veröffentlicht am

Conductor has built an automated CI and CD process which has allowed us to test and deploy high-quality code quickly and reliably. During this presentation, we demonstrated how we leveraged Docker, AWS, TeamCity and other modern technologies to improve and streamline our development process. We also discussed the challenges we face as we shift away from a monolithic build to a microservice architecture.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Continuous Integration and Delivery using TeamCity and Jenkins

  1. 1. CONDUCTOR - AUTOMATING CI AND CD
  2. 2. 2  Introduction  Continuous Integration Overview  Reforming Continuous Integration at Conductor  Common Issues and Mitigations  Deployment Overview  Microservices at Conductor  Q and A AGENDA
  3. 3. 3 WHO WE ARE
  4. 4. 4 WHO WE ARE
  5. 5. 5 “The practice of integrating and testing source code continuously in an automated fashion” WHAT IS CONTINUOUS INTEGRATION?
  6. 6. 6  Minimize the duration and effort required by each integration episode  Be able to deliver a product version suitable for release at any moment OBJECTIVES
  7. 7. 7  Maintain a single source repository  Automate the build  Make Your build self-testing  Keep the build Fast  Test in a clone of the production environment  Automate deployment PRACTICES OF CONTINUOUS INTEGRATION
  8. 8. 8 QUALITY GATES Static Code Analysis Unit Tests Integration Tests Functional UI Tests Performance Tests
  9. 9. 9 REFORMING CI AT CONDUCTOR
  10. 10. 10 · Choose and setup a CI tool · Build and configure Testing Environment · Build a Continuous Integration pipeline · Collect statistics and metrics MILESTONES / GOALS
  11. 11. 11  Choose and setup a CI tool · Build and configure Testing Environment · Build a Continuous Integration pipeline · Collect statistics and metrics MILESTONES / GOALS
  12. 12. 12 CONTINUOUS INTEGRATION TOOLS
  13. 13. 13 CONTINUOUS INTEGRATION TOOLS
  14. 14. 14 Choose and setup a CI tool  Build and configure Testing Environment · Build a Continuous Integration pipeline · Collect statistics and metrics MILESTONES / GOALS
  15. 15. 15  Easy to spin up and maintain  Immutable and disposable Infrastructure  Production-like  Cost effective  Environment agnostic TEST ENVIRONMENT REQUIREMENTS
  16. 16. 16 ORIGINAL TEST ENVIRONMENT
  17. 17. 17 CURRENT TEST ENVIRONMENT PBE Searchlight ZooKeeper WireMock MySQL Thrift Selenium Grid Node Node NodeHub
  18. 18. 18 CONTINUOUS INTEGRATION ARCHITECTURE GitHub Docker Registry TeamCity Master Nexus TeamCity Agent Selenium Grid PBE
  19. 19. 19 Choose and setup a CI tool Build and configure Testing Environment  Build a Continuous Integration pipeline · Collect statistics and metrics MILESTONES / GOALS
  20. 20. 20 PULL REQUEST WORKFLOW Open PR Unit and Integration Tests Jasmine and Karma Tests Linting Launch Selenium Grid Launch PBE Feature Tests Merge PR
  21. 21. 21 PULL REQUEST IN TC
  22. 22. 22 Choose and setup a CI tool Build and configure Testing Environment Build a Continuous Integration pipeline  Collect statistics and metrics MILESTONES / GOALS
  23. 23. 23  “require branches to be up to date before merging” is disabled in Github  To mitigate conflicts we run a “heartbeat” workflow against master every 4 hours  Posts build status into Slack dev channels  PRs are paused in the case of failure PR HEARTBEAT
  24. 24. 24 PR STATISTICS
  25. 25. 25 PR STATISTICS
  26. 26. 26 Choose and setup a CI tool Build and configure Testing Environment Build a Continuous Integration pipeline Collect statistics and metrics MILESTONES / GOALS
  27. 27. 27 COMMON ISSUES AND MITIGATIONS
  28. 28. 28  Inconsistent behavior (flaky tests, code, infrastructure, etc.)  Differences in production and PBE environments  AWS is having a bad day COMMON BUILD PROBLEMS
  29. 29. 29 FLAKY TESTS AND HOW WE MITIGATE THEM Validate artifacts Launch Selenium Grid Launch PBE Rerun Failures Terminate Resources Green Check PR
  30. 30. 30  Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.  It groups containers that make up an application into logical units for easy management and discovery. TEST ENVIRONMENTS ON KUBERNETES Kubernetes Cluster Selenium Grid Hub Node Node Node Searchlight ZooKeeper WireMock MySQL Thrift PBE Selenium Grid Hub Node Node Node Searchlight ZooKeeper WireMock MySQL Thrift PBE
  31. 31. 31 TC CLOUD AGENTS Configured TeamCity with AWS to start and stop images with TeamCity agents on- demand based on the queued builds.
  32. 32. 32 DEPLOYMENT OVERVIEW
  33. 33. 33  Tests similar to those run for PRs are used  Runs on a production-like beta environment  Test results are reviewed  Jenkins job deploys in rolling fashion with zero downtime DEPLOY TESTING
  34. 34. 34 PROD DEPLOY PIPELINE Checkout SCM Schedule Icinga Downtime DB Migrations Deploy UIs Deploy Thrift Post Actions Instance Auto Scaling Group Auto Scaling Group Instance InstanceInstance Instance InstanceInstance
  35. 35. 35 MONITORING
  36. 36. 36  Integrate performance tests into the PR process  Run security scanning as part of PRs  Remove reliance on release testing  Microservices! WHAT’S NEXT?
  37. 37. 37  Large Monolithic applications are complicated!  They create unnecessary dependencies  They are hard to scale vertically and horizontally  Overall velocity and speed is hindered WHY MICROSERVICES?
  38. 38. 38  Define organizational standards for designing, developing, testing and deploying microservices  Use out of the box solutions as much as possible  Build new features as microservices alongside the monolith  Migrate existing features to microservices when necessary GREAT, NOW WHAT?
  39. 39. 39 MICROSERVICE CI/CD Jenkins Dev Kubernetes Cluster (1) a PR is opened against a branch in GitHub (2) Jenkins runs tests against that branch, if successful changes are merged (3) Jenkins runs tests against the head of features, if successful artifacts are published to Nexus and the Docker registry (4) Engineers can deploy their service manually to the development Kubernetes cluster for manual validation during development Prod Kubernetes Cluster (5) Deployments to the production Kubernetes cluster are triggered manually E2E TESTS PERF TESTS SCALE TESTS (6) E2E, performance and scale tests are run in a "blue" environment and if successful the service is switched to "green" Nexus Docker Registry CD Tool LINTING UNIT TESTS CONTRACT TESTS CODE COVERAGE PUBLISH ARTIFACTS GitHub Jenkins LINTING UNIT TESTS CONTRACT TESTS CODE COVERAGE OPEN PR
  40. 40. 40 · Daily monolith deploys · Frequent microservice deploys · Deliver bug fixes and new features faster · Fewer bugs in production · Continued adoption of microservices WHERE WE ARE TODAY
  41. 41. 41 QUESTIONS?

×