Onboarding applications onto Pivotal Cloud Foundry

We often talk about reducing the barrier of entry for developers onto a new platform. Remember your platform - PCF is a product. One of the core advantages of PCF is how it catalyzes developer productivity. This productivity often comes from having an opinionated prescriptive approach to developing apps. With the appropriate gaurdrails and productivity practices in play enterprises can truly harness the power of the platform. In this blog post I put forth the developer workflow for developing and onboarding apps at the highest level of abstraction.

What should be the onboarding process for an app on PCF ?

1. App Developer logs in into the App On boarding portal.  Operators need to automate access to the PCF platform for developers in an enterprise using cf-mgmt with the following commands. 

2. 

   
   

   Customized version of start.spring.io for Java and .NET apps that generates a running app bound to the relevant PCF service - Redis, Rabbit, MySQL, …. Fork this spring intializr repository for customizing start.spring.io.
3. Scaffolding: Portal generates a corresponding CI pipeline that deploys said app to dev space. Reuse spring-cloud-pipelines. Minimal refactoring to comply with basic Spring Cloud Pipelines requirements. At the end of this stage, each app will have a corresponding pipeline on Concourse. The pipelines will successfully build the apps, store the artifacts in Bintray, tag the GitHub repositories, and deploy the apps to Test, Stage, and Prod spaces in Cloud Foundry.
   

   
4. The app generated by the start.spring.io has appropriate tie-ins into credhub and a config server for managing secrets and config respectively.
5. Security integration with the app putting it in the right authentication/authorization flows with Pivotal SSO or custom services
6. Iterate on app features tracking the objectives and key results of the application. 
7. Testing: Add/organize tests to comply with Spring Cloud Pipelines recommendations. Incorporate flyway for database schema versioning and initial data loading. At the end of this stage, the pipelines will trigger unit and integration tests during the Build stage, smoke tests in the Test environment, and end-to-end tests in the Stage environment. The pipelines will also ensure backward compatibility for the database, such that you can safely roll back the backend service app, even after the database schema has been updated. Release workflow pipeline starts to promote the app into test and staging => Blue/Green deploy with tagging in artifactory. Integrate with ESB and other down stream integrations. Insert release mgmt. gate here.
   

   
8. Contracts: Incorporate Spring Cloud Contract to define the API between the UI and service apps and auto-generate tests and stubs.At the end of this stage, the pipelines will catch breaking API changes during the Build stage and ensure backward compatibility for the API, such that you can safely roll back the backend service (producer) app, even after an API change.
9. Pipeline to promote to prod.. This may deploy to multiple foundations. This has the capability to do a canary and dark deploys and rollback. Insert release mgmt. gate here
   

   

References:

• Continuous Deployment to the Cloud - Marcin Grzejszczak, Cora Iberkleid  https://content.pivotal.io/springone-platform-2017/continuous-deployment-to-the-cloud-marcin-grzejszczak-cora-iberkleid
• Migrate Apps to Spring Cloud Pipelines https://cloud.spring.io/spring-cloud-pipelines/multi/multi__step_by_step_cloud_foundry_migration.html