Spring, Spring Boot and Spring Cloud are tools that allow developers to speed up the creation of new business features. But a new feature is only useful if it's in production. Companies spend a lot of time and resources on building their own deployment pipelines using a plethora of technologies. Spring Cloud Pipelines provides an opinionated way for getting your features to production in a fast, reliable, reproducible and fully automated way.
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?
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?
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?
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
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!
22.
23. Anatomy of an opinionated
deployment pipeline
So how does it work?
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
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
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?
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.
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
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
Be clear about what portion of the pipe dreams/vision/circle of code this is addressing - maybe add a slide?
Spring and opinions
Spring projects provide opinions through annotations, the framework…
Spring Boot, JPA, Integration… all provide opinions through annotations
SCP provides the opinions through pipelines
SCP provides template pipelines in Jenkins and Concourse
Concept based on one or two years’ worth of real enterprise work
Maturity: in active development
Blog post by Marcin: Cct 2015
Future: will be partially replaced by Spinnaker, pipelining will be done by Spinnaker; jobs will remain
Spinnaker will call Jenkins jobs to run tests, etc. Spinnaker will orchestrate jobs
Marcin modified surefire plugin in maven to verify that the smoke or end2end tests are under the smoke or end2end package… Meaning when running profile smoke, maven runs tests in smoke package only, etc. In gradle, there is an inclusion pattern that accomplishes the same effect
Could integrate with JUnit annotations…??
SCP in concrete
Concourse Background: Pivotal build CI/CD tool borne out of need for CICD for CF, for managing many services and microservices
Can use Jenkins as well
In Concourse, there is a jenkins.yml file that is the manifest - you can think of it as the blueprint - of how the pipeline should look
You can modify it - provides a set of opinions but you can change it
