I am having a hard time to understand how CodeDeploy will change my current deployment workflow (which consists of git aws.push basically). Can someone here enlighten me?
AWS CodeDeploy
31–40 of 53 posts
Re: AWS CodeDeploy
#32Interesting. 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.
Yeah I was also hoping this would be more something along the lines of the Google App Engine. I like just writing the application's code not having to worry about the stack too much.
Re: AWS CodeDeploy
#33While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. 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, an…
I'm a big fan of Elastic Beanstalk. AWS with Elastic Beanstalk just makes things super easy for my deployment. And today Amazon announced they have over 1 million active users. This just shows how powerful their offerings are.
Re: AWS CodeDeploy
#34Earlier quoted context omitted.
Yep, this is Amazon reaching out to those who won't/can't take the 'immutable infrastructure' approach. It's fair to say if you're already doing things in the way you describe, this service isn't for you.
Baking everything into AMIs is the "right" way to go, but if AWS had a supported, hosted git server inside their network to push into, I'd rather have the speed of deploying from git, and only bake AMIs when necessary for system upgrades.
...and it looks like one's in the works: https://aws.amazon.com/codecommit/
Re: AWS CodeDeploy
#35Earlier quoted context omitted.
I've been working on the CodeDeploy Integration here at Codeship and have been working with the service for a bit (as a preface on my thoughts) 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…
Have you written anywhere how you guys deal with operational monitoring (eg. Boundary, New Relic, etc.) when you're spinning up brand new instances all of the time?
I have used Stackdriver (http://www.stackdriver.com/) before and it works good. It can get a bit pricey. They got bought by Google few months ago -- something to watch out for. I really had a good exp with their product.
Re: AWS CodeDeploy
#36While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. 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, an…
> 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.
Yes. As a frequent Chef user, I was really excited about OpsWorks, but it feels quite beta, and as you said the build/test cycle is even worse than usual for config management.
Have you had any success developing your Chef scripts on Vagrant and then using them on OpsWorks? It seems like the real thing is just too different. The open source OpsWorks cookbooks don't match what's actually running, you've got a VPC environment around you, there are extra tweaks to the AMIs, etc.
For new projects I think CloudFormation + regular Chef is a better way to go.
Re: AWS CodeDeploy
#37I'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 been working on the CodeDeploy Integration here at Codeship and have been working with the service for a bit (as a preface on my thoughts) 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…
I am wondering why you guys don't see CodeDeploy as a competitor to Codeship? or eventually becoming something like Codeship?
Re: AWS CodeDeploy
#38While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. 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, an…
> 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. Yes. As a frequent Chef user, I was really excited about OpsWorks, but it feels quite beta, and as you said the build/test cycle is even worse than usual for config management. Have you had any success developing your Chef scripts on Vagrant and then using them on Op…
I tried getting a Vagrant environment up but I'm not convinced it's worth it. There is at least one repo with what looks like a working config [1].
I was far enough along in development by the time I started messing with Vagrant that I never finished it. I started debugging using the opsworks-agent-cli as mentioned in zackangelo's comment. I'd just been `git push`ing changes, updating cookbooks and testing again - his method of editing cookbooks [2] directly actually sounds rather workable. I imagine in the future I will mostly edit and test cookbooks this way.
1. https://github.com/wwestenbrink/vagrant-opsworks 2. https://news.ycombinator.com/item?id=8598255
Re: AWS CodeDeploy
#39This could be a big deal in terms of raising the bar for deployment practices. Right now "nobody ever got fired for" setting up deployment via rsync and some ad-hoc shell scripts. That works for a single host, although it's not great for reproducibility. But as soon as you go to multiple hosts you need some degree of orchestration, monitoring, and integration with your load balancer to avoid downtime. CodeDeploy offe…
If the job is "get an app onto a bunch of boxes and load balance the healthy ones," I feel like AWS has already been doing that for a long time – deploy your code to a box, create an AMI from the box, and use it as a launch configuration for an auto scaling group. New code=new box=new AMI, and then you don't have to worry about the mechanics of moving code to a bunch of boxes at the same time. This seems like a tiny…
I think immutable infrastructure is probably the way forward, but it's not yet easy enough to be the default for lazy people.
tiny step forward for orgs who are deploying code to boxes that they never take down
That's exactly why this is a clever move - it's a better way to do what you already know how to do. This should get more teams using responsible deployment practices. If you have to first learn a whole new mindset about infrastructure, most people just won't bother, and will keep on rsyncing.
Re: AWS CodeDeploy
#40Earlier quoted context omitted.
I've been working on the CodeDeploy Integration here at Codeship and have been working with the service for a bit (as a preface on my thoughts) 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…
Have you written anywhere how you guys deal with operational monitoring (eg. Boundary, New Relic, etc.) when you're spinning up brand new instances all of the time?
We use stackdriver very heavily - but also take a look at SignalFuse.