Skip to main content
Tag

Spinnaker

Join Us at Spinnaker Live TODAY!

By Announcement, Blog, Staff

Find out why 2020 is the year of Spinnaker at https://Spinnaker.Live on June 18th at 9:00am PDT. Learn how enterprises accelerate with open source Spinnaker at this Linux Foundation virtual conference co-hosted by the CD Foundation and Armory.

Register now!

“The CD Foundation seeks to improve the world’s capacity to deliver software with security and speed,” said Rosalind Benoit, Director of Community at Armory, and Chair of the CD Foundation Outreach Committee. “Spinnaker.Live speaks to everyone invested in software delivery collaboration and automation. Open source is powered by connections, and this event is to meet, connect, and hear great stories. Please bring your energy and ideas to this incredible global community!”

Spinnaker is a free and open source continuous delivery software platform developed by Netflix and Google to create tailor-made, collaborative continuous delivery pipelines. With unique multi-cloud building blocks, it integrates all the tools, approvals, and infrastructure needed to automate an enterprise software delivery lifecycle.

Spinnaker is housed under the CD Foundation umbrella at the Linux Foundation. It is a Founding Project of the CD Foundation. 

Continued Growth in 2020

Spinnaker is continuing to grow in 2020, boasting more contributors and more Pull Requests than ever before.

Key statistics for 2020

  • Q1 2020 was the first quarter since Spinnaker was open sourced that the project had at least 2 new contributors each week
  • Of the 1,183 contributors to Spinnaker in the last year, 464, or 40%, contributed in Q1 2020
  • Merged Pull Requests have skyrocketed in 2020. These are the code and documentation contributions that the project accepts and incorporates.
    • Average since open sourced: 399/month
    • Average in the last 12 months: 605/month
      • Previous high was 656 (March 2019, 1.6x the average since being open sourced)
    • February 674 (1.7x avg)
    • March 891 (2.2x avg)
    • April 962 (2.5x avg)
    • May 755 (1.9x avg)

Notable Amazon Support

Spinnaker has been implemented widely with well known companies like Adobe, AirBnb, Autodesk, Comcast, Salesforce, SAP, and many more using Spinnaker to handle the software delivery life cycle. Of note, Amazon Web Service (AWS) has dramatically increased contributions to Spinnaker in 2020. 

Up-to-date statistics are available on Devstats. They show a strong spike coming into 2020 in AWS contributions, with pull requests in recent months more than tripling 2019’s monthly highs. Amazon has stated publicly that they are backing Spinnaker due to strong enterprise customer demand. 

AWS will be prominently represented at Spinnaker.Live with a keynote, breakout session, panel, and use case talks from AWS experts and companies who deploy software to AWS. Don’t miss it!

Register Now!

DevOps.com: CD Foundation Touts Spinnaker CD Progress

By In The News

At an online Spinnaker Live event today, the Continuous Delivery (CD) Foundation revealed the open source CD platform is gaining significant momentum since being contributed by Netflix late last year.

There were on average 399 merged pull Spinnaker requests a month in the first quarter of 2020. A total of 1,183 contributors participated in the project in the last year, with 40% of those contributors participating in the first quarter. Since the first quarter, the project has added at least two new contributors a week.

Rosalind Benoit, chair of the CD Foundation Outreach Committee and director of community at Armory, a provider of an enterprise edition of Spinnaker, said the bulk of the increased contributions to Spinnaker are coming from Amazon Web Services (AWS), which the cloud service provider is already employing to orchestrate software delivery across multiple platforms.

READ MORE

9 CD Foundation Projects Are Participating in this Year’s Google Summer of Code

By Blog, Staff

The CD Foundation has joined the list of organizations participating in Google’s Summer of Code (GSoc) this year. GSoC is an annual program aimed at bringing more student developers into open source software development. The CD Foundation projects Spinnaker and Screwdriver joined long-time participant Jenkins in providing mentors for a number of projects for students interested in continuous delivery and software pipeline infrastructure.

In total, 7 Jenkins projects, 2 Spinnaker and 1 Screwdriver project were accepted in this summer’s program. Mentors from many different organizations around the world are pitching in, including CD Foundation ambassadors.

“The CD Foundation is dedicated to supporting open source continuous delivery projects worldwide. Part of that mission includes supporting and encouraging the next generation of talented developers worldwide, said Tara Hernandez, Senior Engineering Manager, Google Cloud Platform and CD Foundation Technical Oversight Committee member. “Thank you to the students and mentors who work tirelessly to create and innovate for the GSoC. We hope everyone has a fantastic time coding and learning this summer. Congratulations!”

The following is a list of the projects accepted and links to each project description and associated mentors.

Jenkin’s Projects 

Loghi Perinpanayagam – Jenkins Machine Learning Plugin for Data Science

This project provides a plugin for data scientists to integrate Machine Learning Workflow with Jenkins.

Kezhi Xiong – GitHub Checks API for Jenkins Plugins

The GitHub Checks API allows developers to report the CI integrations’ detail information rather than binary pass/fail build status on GitHub pages.

stellargo – External Fingerprint Storage for Jenkins

File fingerprinting is a way to track which version of a file is being used by a job/build, making dependency tracking easy.

Rishabh Budhouliya – Git Plugin Performance Improvement

The principles of micro-benchmarking were used to create and execute a test suite which involves comparison of GitClient APIs implemented by CliGitAPIImpl and JGitAPIImpl using “average execution time per operation” as a performance metric.

Buddhika Chathuranga – Jenkins Windows Services: YAML Configuration Support

Enhance Jenkins master and agent service management on Windows by offering new configuration file formats and improving settings validation.

Zixuan Liu – Jenkins X: Consolidate the use of Apps / Addons

The main aim of the project is to consolidate Apps and Addons inside Jenkins X to avoid confusion.

Sladyn Nunes Custom Jenkins Distribution Build Service

The main idea behind the project is to build a customizable Jenkins distribution service that could be used to build tailor-made Jenkins distributions.

Spinnaker Projects

Victor Odusanya – Drone CI type for Spinnaker pipeline stage

Add Drone build type as a Spinnaker pipeline stage type.

Moki Daniel – “Continuous Delivery, Continuous Deployments with Spinnaker” 

This project idea will aim at ensuring continuous delivery and continuous deployments, bringing up automated releases, undertaking deployments across multiple cloud providers, and mastering the best built-in deployments practices from Spinnaker.

Screwdriver Project

Supratik Das – Improve SCM Integration

The two key areas where Screwdriver will be improved are introduction of deployment keys for seamless handling of private repositories and triggering of builds from external SCM repositories.

Thank you to all participants! We look forward to getting updates and information on progress over the summer. For more details, please continue to visit the CD Foundation blog.

From Armory – The World of Jenkins: Better #withSpinnaker

By Blog, Member
Jenkins and Spinnaker, Better Together

Originally posted on the Armory blog by Rosalind Benoit

Folks in the DevOps community often ask me, “I’m already using Jenkins, so why should I use Spinnaker?” We’re hosting a virtual talk to address the question! Register here to join us 3/26 and learn how Jenkins and Spinnaker cooperate for safe, scalable, maintainable software delivery.

A delivery engineer I spoke with last week said it best:

“I came from a world of using Jenkins to deploy. It’s great but, you’re just modifying Jenkins jobs. It can do a lot, but it’s like that line in Jurassic Park – ‘Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.’”

Many of us came from that world: we built delivery automation with scripts and tools like Jenkins, CircleCI, Bamboo, and TeamCity. We found configuration management, and used Puppet or Ansible to provision infrastructure in our pipelines as code. We became addicted to D.R.Y. (don’t repeat yourself), and there is no looking back.

Jenkins provides approachable automation of continuous integration steps. Spinnaker works with Jenkins to pick up and deliver build artifacts, and to delegate pipeline stages. As a true continuous delivery platform, Spinnaker codifies your unique software delivery culture and processes to your comfort level. It also adds production-ready value to your pipelines:

  • Turnkey automation of advanced delivery strategies such as canary deployments
  • One-click rollbacks
  • Single pane of glass to view deployments, applications, server groups, clusters, load balancers, security groups, and firewalls
  • Centralized API to automate and integrate across your toolchain

Jenkins taught us many lessons. It popularized the use of imperative pipelines to execute ordered steps in a SDLC. It taught us that centralizing delivery workflows into one platform makes strategic sense in scaling operations. At the same time, especially when used for deployments, it suffers from instability and maintenance overhead brought by unchecked plugin sprawl. It struggles to offer a scalable model for managing multiple jobs and distributed apps. But the way it consolidated SDLC tasks within a full-featured GUI empowered developer teams to start doing delivery.

In the new world of fast innovation through immutable infrastructure, Spinnaker has adapted that visibility to the realms of cloud and cloud native. It provides a centralized vantage point on all of your ephemerally-packaged applications, in their many variations.  Within your pipelines, its guardrails identify invalid or non-compliant infrastructure before deployment even happens. Spinnaker’s smart delivery workflows insulate customers and end-users from impact to their software experience.

This sense of safety is Jenkins’ missing ingredient. Jenkins introduced a world where developers could independently chain together a path to production. It enabled us to improve our efficiency and code quality through testing and build automation, with self-service. This giant technological shift sparked a move away from waterfall development and ITIL-style delivery.

But, culture cannot change overnight. Developers who exercised this newfound power struck terror in the hearts of those accountable for availability and software-driven business goals. Culture lagged behind tooling, sparking fear and risk aversion. That fear still permeates many organizations, allowing baggage-free startups and the most nimble companies to digitally disrupt the status quo. These innovators prove that delivering highly valued interactions through software means increased profit and influence. Enter Armory Spinnaker.


Watch Armory CTO Isaac Mosquera’s Supercharge Your Deployments With Spinnaker and Jenkins presentation at CD Summit, or check out the longer version with Q&A at DeliveryConf.

Stop spending time and talent knitting your toolchain together with pipeline steps that rely on brittle, expensive-to-maintain scripts and repetitive GUI fiddles! Attend “I have Jenkins; why do I need Spinnaker?” to learn more about how Spinnaker can free your developers and evolve your continuous delivery game.

From Armory – Kubernetes Native: Introducing Spinnaker Operator

By Blog, Member

Originally posted on the Armory blog by German Muzquiz

Spinnaker Operator is now Beta!

With Spinnaker Operator, define all the configurations of Spinnaker in native Kubernetes manifest files, as part of the Kubernetes kind “SpinnakerService” defined in its own Custom Resource Definition (CRD). With this approach, you can customize, save, deploy and generally manage Spinnaker configurations in a standard Kubernetes workflow for managing manifests. No need to learn a new CLI like Halyard, or worry about how to run that service.

The Spinnaker Operator has two flavors to choose from, depending on which Spinnaker you want to use: Open Source or Armory Spinnaker.

With the Spinnaker Operator, you can:

  • Use “kubectl” to install and configure a brand new Spinnaker (OSS or Armory Spinnaker).
  • Take over an existing Spinnaker installation deployed by Halyard and continue managing it with the operator going forward.
  • Use Kustomize or Helm Charts to manage different Spinnaker installations with slight variations.
  • Use Spinnaker profile files for providing service-specific configuration overrides (the equivalent of clouddriver-local.yml, gate-local.yml, etc.)
  • Use Spinnaker service settings files to tweak the way Deployment manifests for Spinnaker microservices are generated.
  • Use any raw files needed by configs in the SpinnakerService manifest (i.e. packer templates, support config files, etc.)
  • Safely store secret-free manifests under source control, since a SpinnakerService manifest can contain references to secrets stored in S3GCS or Vault (Vault is Armory Spinnaker only).

Additionally, Spinnaker Operator has some exclusive new features not available with other deployment methods like Halyard:

  • Spinnaker secrets can be read from Kubernetes secrets.
  • Spinnaker is automatically exposed with Kubernetes service load balancers (optional).
  • Experimental: Accounts can be provisioned and validated individually by using a different SpinnakerAccount manifest, so that adding new accounts involves creating a new manifest instead of having everything in a single manifest.

Let’s look at an example workflow.

Assuming you have stored SpinnakerService manifests under source control, you have a pipeline in Spinnaker to apply these manifests automatically on source control pushes (Spinnaker deploying Spinnaker) and you want to add a new Kubernetes account:

  1. Save the kubeconfig file of the new account in a Kubernetes secret, in the same namespace where Spinnaker is installed.
  2. Checkout Spinnaker config repository from source control.
  3. Add a new Kubernetes account to the SpinnakerService manifest file, referencing the kubeconfig in the secret:
apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
name: spinnaker
spec:
spinnakerConfig:
config:
version: 2.17.1 # the version of Spinnaker to be deployed
persistentStorage:
persistentStoreType: s3
s3:
bucket: acme-spinnaker
rootFolder: front50
+ providers:
+ kubernetes:
+ enabled: true
+ accounts:
+ - name: kube-staging
+ requiredGroupMembership: []
+ providerVersion: V2
+ permissions: {}
+ dockerRegistries: []
+ configureImagePullSecrets: true
+ cacheThreads: 1
+ namespaces: []
+ omitNamespaces: []
+ kinds: []
+ omitKinds: []
+ customResources: []
+ cachingPolicies: []
+ oAuthScopes: []
+ onlySpinnakerManaged: false
+ kubeconfigFile: encryptedFile:k8s!n:spinnaker-secrets!k:kube-staging-kubeconfig # secret name: spinnaker-secrets, secret key: kube-staging-kubeconfig
+ primaryAccount: kube-staging
  1. Commit the changes and open a Pull Request for review.
  2. Pull Request approved and merged.
  3. Automatically a Spinnaker pipeline runs and applies the updated manifest.

We hope that the Spinnaker Operator will make installing, configuring and managing Spinnaker easier and more powerful. We’re enhancing Spinnaker iteratively, and welcome your feedback.

Get OSS Spinnaker Operator (documentation)

Get Armory Spinnaker Operator (documentation)

Interested in learning more about the Spinnaker Operator? Reach out to us here or on Spinnaker Slack – we’d love to chat!