11–20 of 53 posts
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
At my org, we currently use a very similar method of deployment that AWS CodeDeploy seems to provide, except that we wrote it in house and use some python fabric scripts to do it. It sounds like AWS CodeDeploy would help us to "AWSify" this method of deployment and also have some nice benefits of health checks/rollbacks, UI based management, and a deployment history log. However, we would essentially still be maintaining/writing bash/python scripts to do the heavy lifting.
However, we are in the process of moving to a method of deployment which uses SaltStack to prebake an AMI with everything that is required to run in production and then use Netflix's Asgard to manage the deployment of the prebuilt AMIs. We are very excited about this method of managing deployments to take advantage of AutoScaling groups and using a well defined/tested stack of tools.
Interested to hear thoughts from others using a deployment approach that they think would benefit from AWS CodeDeploy.
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
It's fair to say if you're already doing things in the way you describe, this service isn't for you.
Is this going to integrate with Docker? Would make a great orchestration platform
Is this going to integrate with Docker? Would make a great orchestration platform
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
Looks like an improved version of OpsWorks
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
While Immutable Infrastructure is also in our opinion (and I've written about this extensively) the way to go in the future updating systems in place is still the primary way to deploy systems and will be for a while. By providing a centralized systems to upload new released and manage the deployment (how many instances get the new deployment in which timeframe) you can take away some of the security problems of opening up ports for access and potential deployment errors where the SSH connection dies.
Especially when deploying into a large infrastructure connecting into each instance for update becomes painful. That's where an agent based services like CodeDeploy is really powerful and removes the single point of failure that is the machine/network that you deploy from.
With ElasticBeanstalk, Opsworks and Cloudformation they now really start to surround all the deployment workflows.
Definitely a great service that will in my opinion become very important to many many teams. You can also read more about our specific integration in our blog: http://blog.codeship.com/aws-codedeploy-codeship/
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seco…
Deploy and rollback doesn't happen on live instances. (Group of) Instances are taken off service for rolling deployment and you can configure what percentage of your fleet should be deployed to at once.
Interesting. Between Elastic Beanstalk, OpsWorks, and now CodeDeploy it seems like AWS is taking over every production developer workflow from the hobbyist on up.
I find none of them good enough for my workflow. I think heroku nailed it with their deployment approach for my case. Beanstalk worker tiers are a nightmare. You need to place all your workers in separate repos, for example for git aws.push style workflow to work.
I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, and the feedback cycle when attempting to develop new cookbooks is excruciatingly slow.
All I want, personally, is a system that uses a set of interchangeable scripts that represent dependencies, so my server configs can live in version control. It doesn't even need to run on multiple OSs (which seems to be a central tenet of Chef). It just needs to deploy/rollback with zero downtime, and ideally autoscale as quickly as possible. Is this it? Is there any way to know without spending weeks fleshing out how it works?