Regarding areas for improvement, one significant issue is the lack of maker-checker flows to ensure that newly created pipelines are accurate and tested. We currently use an in-house abstraction over Spinnaker to verify pipeline specs, environment variables, etc. It would be beneficial if Spinnaker could offer this functionality within their product.
I am not sure if anything can be improved in Spinnaker because it was written and designed before Kubernetes was around. All of its authentication, role-based access control, application definition, and other stuff happen outside of Kubernetes, so Spinnaker is not a Kubernetes-native tool. You have to mimic a lot of the stuff you already have the provisions for in Kubernetes. Kubernetes also has parallels to what it is in Spinnaker. If your deployment infrastructure is Kubernetes, to get it running on Kubernetes takes a lot of customizations that you have to do, and it is something that the company has done. One of the downsides of Spinnaker is its scalability. The amount of data that it stores in each pipeline or from a pipeline context is huge. Every time it goes to run a pipeline, it just generates a lot of data, and its database is not exactly tuned out of the box, meaning it is not tuned for high scalability. You start to run a bunch of pipelines in parallel, and very quickly, within a couple of hundred pipeline runs, you start to run into scalability and performance issues.
In some cases, in terms of the Trinity feature, when it tries to communicate with AWS CloudFormation, and we try to deploy the instance or any container service, if any connectivity issues happen, the pipeline can fail. An error appears simply as a Trinity error, or some common error. It never shows exactly why it's failed and where it failed. Sometimes, we have to go and re-trigger or re-run the entire pipeline or reset the particular stage to make the deployment successful. Log-wise, we need to understand why something has failed so that we can understand and try to fix it the moment the issue is reported. The solution could use more robust monitoring. There are many features we can compare with Jenkins. For example, how the plugins are set up and how to customize things. For example, for Kubernetes, we have Grafana, and again, it's a separate tool. We'd like everything to come in a single tool and have the pipeline, its main dashboard, show us everything that needs to be monitored. For example, if you take in Jenkins, there is a feature called Blue Ocean. Over Blue Ocean, instead of console output, we can see how the stage is going. The graphics could always be better.
Application release automation (ARA) is the process of packaging and deploying an application or software update. ARA goes from development through production. The process, and the tooling that makes it happen, brings together solutions that automate deployment, manage and model environments and coordinate releases. ARA solutions sometimes form part of the broader DevOps process.
When PeerSpot members write about their preferences for Application Release Automation software, the word...
Regarding areas for improvement, one significant issue is the lack of maker-checker flows to ensure that newly created pipelines are accurate and tested. We currently use an in-house abstraction over Spinnaker to verify pipeline specs, environment variables, etc. It would be beneficial if Spinnaker could offer this functionality within their product.
I am not sure if anything can be improved in Spinnaker because it was written and designed before Kubernetes was around. All of its authentication, role-based access control, application definition, and other stuff happen outside of Kubernetes, so Spinnaker is not a Kubernetes-native tool. You have to mimic a lot of the stuff you already have the provisions for in Kubernetes. Kubernetes also has parallels to what it is in Spinnaker. If your deployment infrastructure is Kubernetes, to get it running on Kubernetes takes a lot of customizations that you have to do, and it is something that the company has done. One of the downsides of Spinnaker is its scalability. The amount of data that it stores in each pipeline or from a pipeline context is huge. Every time it goes to run a pipeline, it just generates a lot of data, and its database is not exactly tuned out of the box, meaning it is not tuned for high scalability. You start to run a bunch of pipelines in parallel, and very quickly, within a couple of hundred pipeline runs, you start to run into scalability and performance issues.
Spinnaker's configuration setup is too complicated and should be made easy. While configuring Spinnaker, we need to get a CLI tool called Halyard.
In some cases, in terms of the Trinity feature, when it tries to communicate with AWS CloudFormation, and we try to deploy the instance or any container service, if any connectivity issues happen, the pipeline can fail. An error appears simply as a Trinity error, or some common error. It never shows exactly why it's failed and where it failed. Sometimes, we have to go and re-trigger or re-run the entire pipeline or reset the particular stage to make the deployment successful. Log-wise, we need to understand why something has failed so that we can understand and try to fix it the moment the issue is reported. The solution could use more robust monitoring. There are many features we can compare with Jenkins. For example, how the plugins are set up and how to customize things. For example, for Kubernetes, we have Grafana, and again, it's a separate tool. We'd like everything to come in a single tool and have the pipeline, its main dashboard, show us everything that needs to be monitored. For example, if you take in Jenkins, there is a feature called Blue Ocean. Over Blue Ocean, instead of console output, we can see how the stage is going. The graphics could always be better.