[DEPRECATED] Codebase containing Concourse and Jenkins opinionated pipelines. Moved to https://github.com/CloudPipelines/
Spring Cloud Pipelines is a GitHub project that tries to solve the following problems:
The first commit took place on 31-08-2016. Since then, we have gotten a lot of feedback from the community related to the suggested deployment pipeline and its concrete visualisations. Over those two years, the most important features we have managed to build are:
We would like to announce the next 1.0.0.M9 release of Spring Cloud Pipelines, which will also be its last in the current form.
Since I'm a member of the Spring Cloud team, we have decided to put it under the Spring Cloud umbrella. Other than that, the project has nothing to do with Spring Cloud, not to mention Spring in general.
That is why we have decided to split the project into pieces, rename it, and put it into a separate GitHub organization.
Spring Cloud Pipelines has a new home and a new name. The projects now lays under the https://github.com/CloudPipelines/[Cloud Pipelines] organisation at GitHub. The project, as a result, was split into the following pieces:
recipes. Each recipe contains a step of the deployment pipeline. The documentation is here.After migrating the projects to the new organisation, we have decided to mark them as feature complete. Of course, we will facilitate any discussions around the project and chores related to issues, pull requests and releases, but we can safely state that the project will be fully driven and maintained by the community.
If you are interested in migrating your project from Spring Cloud Pipelines to Cloud Pipelines, you should check out the migration guides:
Spinnaker is an open source multi-cloud continuous delivery platform which started at Netflix but now involves a wider community of contributors from Google, Amazon, Pivotal, and many others. A collaborative effort by the Spring team and Pivotal Cloud R&D has led to Cloud Foundry support in Spinnaker.
Spinnaker gives us access to a wider array of supported cloud providers without having to reinvent these interactions.
The work to-date on zero-downtime deployments and rollback testing in Cloud Pipelines reveals a key value of a continuous delivery platform like Spinnaker that separately maintains an inventory of the assets in your deployed environments.
In Cloud Pipelines, the current production system state was not being stored. To mitigate this issue we used the Git tags to store state. That, however, can be easily broken when manual deployments or rollbacks take place. Also, the production system state may span multiple versions (across cloud providers or regions) and is in general irreducible to a single value that can be stored in a tag. A Spinnaker pipeline performing, for example, a rollback test is free to use Spinnaker’s knowledge of the state of the system to contextualize the rollback test to the production version in the target regions independently of one another.
The deployment options provided in Cloud Pipelines are limited. Spinnaker generalizes blue/green, rolling push, zero-downtime and automated canary analysis deployment features across a range of supported cloud providers.
To be more concrete, consider blue/green deployment. Spinnaker supports blue/green while maintaining an arbitrary number of prior version server groups. From the current version of the app in the below example, you are one action away from rolling back to a version of the app that is several versions from the most recent. At any time, we could choose to destroy V022, effectively making it unavailable to roll back to. Such a thing could happen out-of-band from a deployment activity (such as to free capacity), making stateless systems less able to deal with change.
We welcome your input, in a variety of forms. If you have questions about Spinnaker, ask on Stack Overflow and use the #spinnaker tag. In case of Cloud Pipelines, ask questions on GitHub. If you want to work on the code, we love pull requests. If you spot a problem, please submit an issue on Github.
This release adds a lot of new features and quality and testing improvements. As for main features, we've added support for a project with multiple modules, and for mono-repos (projects with standalone application sources in it). As for quality and testing, we're approaching 200 Bash tests (we've written missing tests for the Concourse pipeline). We've started publishing the project's sources as a downloadable artifact. That way instead of cloning the repo or downloading the ~25mb archive, you can fetch around 150kb of sources. The docs for 1.0.0.M8 are available here - http://cloud.spring.io/spring-cloud-static/spring-cloud-pipelines/1.0.0.M8/
We're attaching the distributions to this release in tar.gz and zip formats, with sources only.
Below you can find more detailed release notes:
sc-pipelines.yml file in pipelines [#127]deployGreen or switchBackToBlue functions got removeddev/1.0.0.M1 to dev/projectName/1.0.0.M1
Super special thanks go to the one and only @ciberkleid for all her hard work on the project (look at that!!! - https://github.com/spring-cloud/spring-cloud-pipelines/pull/130/) and to @oiavorskyi (https://github.com/spring-cloud/spring-cloud-pipelines/pull/148) Kudos Cora and Oleg!
Special thanks go to @regevbr and everybody involved in the project!
This release adds a lot of new features and quality and testing improvements. As for main features, we've added Kubernetes support for Jenkins and Concourse. As for quality and testing, we've written over 150 Bash tests, added Shellcheck, EditorConfig and written more Jenkins tests. We've also unified the project's documentation that now can be available for each milestone under Spring Cloud Static gh-pages. The docs for 1.0.0.M7 are available here - http://cloud.spring.io/spring-cloud-static/spring-cloud-pipelines/1.0.0.M7/
Below you can find more detailed release notes:
init.groovy [#72]Special thanks go to @wybczu, @malston , @bijukunjummen, @anwarchk and everybody involved in the project!
Features:
pipeline.yml where you define necessary infrastructure applications to be deployed for tests [#71][#66]Bug fixes:
prod tags from sample repos enhancement [#64] by @wybczuRefactoring:
Documentation fixes:
With 1.0.0.M5 we've added a new step in the Build stage called API Compatibility check. Now, your pipeline can break when, as a HTTP / messaging producer, you're doing a backward incompatible change. We're checking what were the latest contracts you've defined for your most recent production deployment and from those contracts we're generating tests to your current application.
Also @ryanjbaxter has added support for GPG keys.
in this release we've added:
in this release we've added:
now we also support Gradle projects out of the box; also minor fixes were applied