Share your experience using Plutora

My usual use cases for AWS CodeDeploy involve utilizing it as an AWS service, which is a subservice of CodePipeline. AWS CodePipeline is a whole package of services which consists of AWS CodeDeploy and CodeBuild, all together forming a full-fledged pipeline for AWS Cloud. If you are looking for a pipeline and you are already a customer of AWS, then that's a go for you there.

In terms of flexibility, we have only used AWS CodeDeploy for cloud deployments; we do not have any on-premises servers for AWS CodeDeploy. The only on-premises resource we have is a database on AS/400, which does not require deployment. Thus, our company has a strictly cloud use case for AWS CodeDeploy.

The features and capabilities of AWS CodeDeploy that I have found most valuable are that it is very user-friendly, and the codebase we can use there, specifically the tech stack, is YAML configuration. YAML is quite user-friendly itself, so if you just understand the basic concepts of YAML, then you're good to go. However, people face some problems with the YAML tech stack, as it is very strict with indentation and the placement of attributes. Overall, it's very strict with indentation and how it interprets our input. For example, in a stage where an environment is defined, there should be two spaces followed by an environment key and value. Knowing YAML is essential before working on AWS CodeDeploy, as the YAML file controls the service.

AWS CodeDeploy's integration with other AWS services contributes significantly to scaling, monitoring, and security in my deployment processes by requiring IAM permissions. This is the only gateway for it to obtain permission to perform any tasks or triggers. One advantage we have with AWS CodeDeploy is its hassle-free accessibility through IAM roles and permissions. Being an AWS service, it operates on ARNs, which are identifiers. When we refer to these codes in IAM policies, we can give specific permissions while adhering to the least privileges rule of IAM. This makes it quite good and flexible with AWS resources, unlike third-party options.

AWS CodeDeploy could improve in several areas. While it handles everything and operates as a cloud service managed by AWS, its pricing can be reconsidered. There are too many options available for connecting repositories to AWS CodeDeploy for pulling code and building outputs. Additionally, it should provide more flexibility with the YAML structure, particularly in checking indentation within AWS CodeDeploy itself, instead of requiring third-party applications. Overall, it looks good without major drawbacks.

I have been using AWS CodeDeploy for around two years.

I have not utilized AWS CodeDeploy's blue/green deployment feature because I recently used blue/green deployment in Jenkins CI/CD. Since it's an AWS CI/CD, we have only used this for a single use case. Blue/green deployment is a whole new architecture where two deployments happen one after the other, and we didn't find it feasible to proceed with AWS CodeDeploy for blue/green deployment.

I consider AWS CodeDeploy to be stable, but it could be better in certain aspects. It works for single-user use and can be utilized by multiple teams. However, I have faced issues with the YAML structure in CodeDeploy, including difficulties in storing secrets. AWS does offer Secrets Manager as a vault, but the lack of a dedicated secret storage system within AWS CodeDeploy itself can impact its robustness. Other services, such as GitHub and CircleCI, possess built-in mechanisms for environment variables and secrets, making them more efficient. Thus, if AWS CodeDeploy could flesh out its secret management better, it would enhance its overall stability.

I view AWS CodeDeploy as scalable because there are servers in the background. If you're running a simple build, it operates on Linux or Ubuntu servers, and for iOS builds, it utilizes macOS servers. AWS CodeDeploy is not merely a cloud service; it has its own structured working framework behind the scenes. The AWS team manages scalability, so if your workspace imposes a heavy load, AWS handles that load management for you, although this attention to scalability may impact billing during the billing period.

I would rate the technical support for AWS CodeDeploy an eight out of ten.

Positive

Before using AWS CodeDeploy, my experience with iOS deployments was nonexistent, but for other deployments, we initially used Jenkins and later CircleCI, which offered 20,000 credits for free. Due to the restrictions associated with AWS CodeDeploy, I opted for CircleCI. Ultimately, we shifted to GitHub Actions as it provides 30,000 credits for free during the initial period, making our deployments based on GitHub Actions rather than AWS CodeDeploy due to cost constraints.

Regarding the initial setup of AWS CodeDeploy, I can say that as I started around two years ago, the navigation was quite complex initially due to having to understand multiple resources: CodeBuild, AWS CodeDeploy, AWS CodePipeline, and CodeArtifact. I needed to familiarize myself with what each of these resources does, how they function, and their background workings. This required time and thorough research before I began utilizing them effectively. Setting aside time for R&D is essential before getting started with any resource.

I find it mandatory to integrate monitoring and logging when using AWS CodeDeploy because it is crucial to have total knowledge of what is happening during the deployment of our code structure to a server or a static resource S3. For this purpose, we use CloudWatch, which is a pre-built option we can select during configuration. This logging and monitoring resource provided by AWS helps developers or DevOps engineers to troubleshoot issues with ease. After deployment, monitoring is also essential as we can check the availability of resources and ensure their health status. Integrating all kinds of monitoring features is mandatory and flexible for developers, DevOps, or anyone involved.

One of the positive impacts I have noticed from working with AWS CodeDeploy is that when I recently needed to build a pipeline for iOS apps, it required a macOS server fitting within the company's budget. If it did not fit, we would have had to look for alternatives. AWS CodeDeploy had its own pre-built environment for iOS deployment, which allowed us to choose it over other alternatives as the iOS code build requirements were quite specific. AWS CodeDeploy handles everything, allowing us to simply provide commands in the form of a YAML file, taking care of all the back-end activity for us.

I have not used the automatic scaling feature of AWS CodeDeploy myself because my primary focus has been on building applications and pushing them to TestFlight or the Apple Developer account. There has been no need for deployment in this case, just a build and product export. As such, we haven't required any high availability or scaling for our tasks.

In terms of pricing and return on investment with AWS CodeDeploy, I reflect on the initial period where we faced numerous errors and troubleshooting challenges, resulting in significant bills. The auditing process was extensive as we had to clarify the reasons for these high costs, which the company had to absorb. For macOS fleets, documentation indicates that a server instance can be reserved for a minimum of 24 hours. This means if a person uses AWS CodeDeploy even once, they reserve that instance for the entire 24 hours and incur charges for that time. Therefore, if daily use occurs, it leads to continual billing. This aspect of pricing created some frustration, and I've participated in many meetings discussing these audits.

I have not decreased my personal usage of AWS CodeDeploy, but in the context of my company's budget and environment, my company recently stopped utilizing AWS CodeDeploy. Specifically, this change occurred about a week ago. While it may seem I have stopped using AWS CodeDeploy, I still work hands-on with YAML regularly, utilizing it daily for Kubernetes and other tech stacks. Additionally, I have my own personal AWS account, where I continue to test various services to ensure I remain up-to-date.

My overall rating for AWS CodeDeploy is 8 out of 10.

We were explaining how to set up the project itself, which describes the main use cases for Digital.ai Agility. This includes how to set up the workflow and how to manage and build a Kanban. I wanted to set up a Kanban, as I am a Kanban trainer. That is where my bias is towards Kanban. I was looking towards those capabilities where I can set a Kanban and get the team collaboration running, and how a full system can be set up.

When they demoed it, they showed it, and Digital.ai helped with those key queries regarding support for this type of setup. However, after that, I couldn't personally explore it, to be frank.

The solution is excellent for collaboration. From the agility point of view, they have very good sprint functionality, allowing you to set up sprints effectively. For Scrum teams, it is particularly good and easy to set up. With respect to sprints and getting metrics out, such as velocity and related measurements, the functionality is robust.

The Scrum boards are particularly effective. Based on my colleague's exploration and setup, I observed how easily the team was able to use it. The integration with that tool was particularly helpful.

It was not supporting some plugins. We wanted to migrate data that we were already using. The migration of data and getting it up and running from the legacy system took some time to get accustomed to.

I conducted the comparative analysis in 2024, within the last 12 months.

To set up the project, it took around 5 to 10 days for one of our projects. Initially, team members struggled, but afterward they adapted because everyone wanted different matrices, and they had many good options. That is where they were helping each other, which caused a slight delay. Other than that, setting up and using it was straightforward.

I would rate the support at seven out of ten. There were some communication gaps, specifically language barriers. We don't have local support in India, which was somewhat hampering.

Positive

Some customization was done regarding dashboards. Though it was around one year back, I'm not able to recall specific details as my team handled it. We received good support from Digital.ai Agility when we got the customized dashboard.

Digital.ai Agility has a bigger reach because it has many good integration points. It can be a one-stop solution for different needs, eliminating the need to use multiple pieces of software. However, it somewhat lacks from the marketing side, as people were not able to actually find the tool. Compared to Jira, it is more expensive. Jira has been giving some plugins these days, so people are content with what they have and are not investing in alternatives at present. Overall rating: 7 out of 10.