The document discusses Spring Cloud Pipelines, which provides an opinionated continuous integration and continuous delivery (CI/CD) pipeline for deploying applications. It outlines the challenges of traditional CI/CD approaches and how Spring Cloud Pipelines addresses them by standardizing and automating the pipeline. The key aspects covered include: - The anatomy of an opinionated pipeline, including environments like build, test, stage, and production. - How the pipeline incorporates different types of automated testing at each stage, from unit to integration to smoke tests. - The typical steps in the pipeline like building, testing API compatibility, deploying to environments, smoke testing, rolling back if needed, and deploying to production.

1. © Copyright 2017 Pivotal Software, Inc. All rights Reserved. Version 1.0
Lars Rosenquist
May 2018
Cloud Native CI/CD with
Spring Cloud Pipelines

2. Cover w/ Image
Agenda
■ Introduction
■ Why Spring Cloud Pipelines?
■ Anatomy of an opinionated deployment
pipeline
■ Demo
■ Q+A

3. Introduction
So what’s this about?

4. Lars Rosenquist
● Platform Architect at Pivotal
○ Field organisation
○ Helping customers become great software companies
● Developing software professionally since 1998
○ Financial, governmental, commercial
○ Java, Spring, Cloud Foundry
● Twitter: @larsrosenquist
● Email: lrosenquist@pivotal.io
About me

5. About you
How is CI/CD setup in your organization?
● Do you have a pipeline for every piece of software you build?
● How much effort (time, steps) does it cost to setup a new pipeline?
● Is it standardized, based on best practices? Or every app its own custom pipeline?
● Do your pipeline(s) make manual testing obsolete?
● Who’s doing CI? Who’s doing CD?
○ CI - Build and run tests
○ CD - The confidence to deploy to production in a fully automated way
● When to deploy to production? Office hours? Evenings/weekends?

6. CI/CD is hard!

7. Challenges with build server
● Setting up build server can be hard
○ Jenkins, (XML) jobs or (Groovy) pipelines
○ Concourse, (yaml) pipelines
● Lots of work in automating jobs and tests
○ Different pipeline for each app
○ Maintenance headache
● Pipeline setup is a chore. Why not automated?
CI/CD is hard (1/2)

8. Challenges on test environments
● Dependent services and applications
○ Available in test environment? Correct version?
● Dependent test data (sets)
○ Available in test environment?
○ Setup? Cleanup?
● Multiple teams in same environment
○ Wait until environment is ‘free’
● And then again for staging and production
CI/CD is hard (2/2)

9. We move to a microservices architecture
● Increases number of applications
● Increases number of dependencies
● Increases complexity
● Increases (wait) time
● Increases costs
And then?

10. So we go from this

11. To this

12. And ultimately this

13. We need
● Standardized and automated way of building our applications
● Standardized and automated way of deploying our applications
● Standardized and automated way of doing various kinds of tests
How do we fix this?

14. Why pipelines?
So how do pipelines help?

15. What does a good CI/CD pipeline look like?
A good pipeline
● Consistent, automated and repeatable steps
○ Build, test, deploy
○ Guarantee of success against a given set of tests
● Testing
○ Rollback testing
○ Backwards compatibility on DB schema changes
○ Use stubs for dependencies
● Zero downtime updates
○ Rolling, blue/green deployments

16. But that’s not all
Also use pipelines for
● Create new uSVC
○ App scaffolding (project structure, Spring/Boot/other libraries)
■ E.g. start.spring.io via curl
○ Build pipeline
○ Tracker/JIRA
○ Wiki/Confluence pages, etc.
● Managing your platform(s)
● Your use case here

17. Spring Cloud Pipelines
Introducing

18. Provide a common way of running, configuring and
deploying applications
Solve for:
- Creation of a common deployment pipeline
- Propagation of good testing & deployment
practices
- Speed up the time required to deploy a feature to
production
The goal

19. What it is...
- An opinionated pipeline to continuously deploy applications
to either Cloud Foundry or Kubernetes
- A mechanism to encourage /enforce best practices ranging
from increased automated test coverage, versioned
database schemas, and contract-based APIs
- Templates and scripts for easily creating standardized
pipelines for Concourse or Jenkins, and integrating with a
git source code repo and a maven artifact repo
- Easily extensible / customizable

20. What it isn’t...
- Your typical Spring project
- Annotations to add to your code
- Libraries to add to your application
- Turnkey solution
- A silver bullet or golden hammer

21. How do I use it?
- https://github.com/spring-cloud/spring-cloud-pipelines
- Treat the project as a template for your pipeline
- Download the repository and use it to init a new
git project
- Modify your new project to suit your needs
- We have our opinions
- But you have yours
- More important: standardize/automate!

23. Anatomy of an opinionated
deployment pipeline
So how does it work?

24. The Big Picture on Jenkins

25. The Big Picture on Concourse

26. Pipeline
● Different environments/phases
● Most of it is deployment and testing
So what’s in the picture

27. Environments
Anatomy of an opinionated pipeline

28. Build
● Local build environment
● No dependencies or other apps
● CICD tool worker
Environments

29. Test
● Remote deployment environment
● Not production-like
● Shared with multiple teams
● Dependencies or other apps may or may not be present, so use stubs
Environments

30. Stage
● Remote deployment environment
● (Tries to be) production-like
● Shared with multiple teams
● Dependencies or other apps present, so no stubs
○ Correct state
○ Correct version
● Need to wait for time slot
○ Until environment is in correct state
○ No one else is using it when you run a (load) test
Environments

31. Prod
● Where our customers go
● Definitely production-like
○ Probably the only one that is. ;)
● Do you verify production?
● Collect metrics?
Environments

32. Tests
Anatomy of an opinionated pipeline

33. Automated testing
● Who does this in a structural and automated way?
● Who knows the testing pyramid?
● If not structural and automated, how then?
Tests

34. Tests

35. Unit tests
● Executed during build phase
● No dependencies
● Fast
● A lot of them
● Do you write before or after writing your code?
Tests

36. Integration tests
● Executed during build phase
● Integrated, but stubbed database/HTTP endpoints
● More expensive, so less amount than unit tests
Tests

37. Smoke tests
● Executed on a deployed application
● Only primary, most critical features
● Executed against an application surrounded by stubs
Tests

38. End to end tests
● Executed on multiple deployed applications
● Only primary, critical usage scenarios
● Executed against multiple applications and all of their dependencies
Tests

39. Performance tests
● Can your application(s) handle a certain load within parameters
○ Throughout
○ Response time
● Run against test (stubbed)
● or stage (end to end)
Tests

40. So about end to end testing
End to end testing
● End to end tests is supposed to be prod-like
● But in reality, most E2E testing is not (dependencies, versions, data, etc.)
● False sense of security/trust (doesn’t really protect against issues)
● Very complex to maintain
● In the end doesn’t work
● Is it just to check off responsibility/blame?

41. So what if we just ….

42. Get rid of end to end testing?

43. Getting rid of end to end testing
Benefits
● Replace with contract testing and stubs (e.g. Spring Cloud Contract)
● No need to deploy additional applications
● Stubs are the same as used in integration tests
● Stubs tested against the application that produces them (use Spring Cloud Contract)
● Tests will be a lot faster -> faster pipeline -> faster to production
● No waiting for other teams or preparation of testing environments
● Less resource (VM) usage

44. Getting rid of end to end testing
Drawbacks
● Your end to end test will be production
● First time applications will communicate will be production
● Do you really trust your tests enough?
● Can you detect in production if something goes wrong?

45. Use contract testing to replace end to end
Replace with contract testing and stubs, only if
● Your microservice architecture if mature
○ Well defined bound contexts
● Your contract testing is mature
○ Proper scenarios in place
○ Builds trust
● You have KPI/monitoring in place on PROD
■ Prometheus/Graphite/Grafana/Seyren/etc.

46. Steps
Anatomy of an opinionated pipeline

47. Pipeline steps
Basic layout
● Test application in isolation
● Test backwards compatibility so it can be rollback in case of failures
● Test deployed version of the application
● User acceptance/performance test on deployed environment (or use…;))
● Deploy to production

48. Build and upload
● Build and publish to artifact repository
● Generate stubs for REST interfaces
● Build and publish Docker image (if Kubernetes)
Steps

49. API compatibility check
● Make sure API changes don’t break current production version (if available)
● Test against API contracts of -1 version (if available)
Steps

50. Deploy to test platform
● Cloud Foundry space or Kubernetes namespace
● Application deployed in isolation with necessary stubs
● Test database migration (if applicable)
○ Flyway, Liquibase
Steps

51. Smoke test new version on test platform
● Execute against stubbed application in isolation
● Best practice
○ A few critical use cases
■ Is primary functionality working?
○ Keep relatively small/limited
■ Want to keep it quick
Steps

52. Deploy rollback on test platform
● Deploy current production version
● Maintain migrated database (to check backwards compatibility)
Steps

53. Smoke test production version on test platform
● Execute another smoke test
Steps

54. Deploy to staging platform for end to end test
● Deploy application alongside other microservices
● No stubs
● Test database migration
● Or use contract testing and stubs!
Steps

55. End to end test new version on staging platform
● Execute against non-stubbed application
● Best practice
○ Hard to maintain, so
■ Only a few critical use cases
■ Keep relatively small/limited
○ Use contract testing and stubs instead
Steps

56. Deploy to production platform
● Tag in git
● Blue-green deployment to new version
● Great success!
● Or is it?
Steps

57. Rollback production platform
● Restore traffic to previous version
● Remove latest production tag in git
Steps

58. Demo/tour!
Now show me the money