Essentially they talk about having good metrics can be vital for going
to a continuous deployment type setup. It's very helpful to have a
graph you can watch after deploying and see: oh no, my errors per min
is going up/response time is going down/whatever metric is important
to your business is going down - I need to look into this.
On Thu, Aug 16, 2012 at 4:39 PM, Nahum Wild <nahum.w...@gmail.com> wrote:
> anyone do this? recommend any tools for it? tips of what not to do?
> we've got some new small apps (moving to SOA) and would like to try this
> out.
> cheers,
> nahum
> --
> You received this message because you are subscribed to the Google Groups
> "WellRailed" group.
> To post to this group, send email to wellrailed@googlegroups.com.
> To unsubscribe from this group, send email to
> wellrailed+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/wellrailed?hl=en.
I've listened to that podcast already, it's pretty interesting.
As we're building new apps we're requiring metrics just like we *cough*
require tests. Currently using Redis to track current state of the system
then using the below node lib to subscribe to keys and show live changes
via websockets.
> Essentially they talk about having good metrics can be vital for going
> to a continuous deployment type setup. It's very helpful to have a
> graph you can watch after deploying and see: oh no, my errors per min
> is going up/response time is going down/whatever metric is important
> to your business is going down - I need to look into this.
> Might be relevant and/or interesting.
> -Malcolm
> On Thu, Aug 16, 2012 at 4:39 PM, Nahum Wild <nahum.w...@gmail.com> wrote:
> > anyone do this? recommend any tools for it? tips of what not to do?
> > we've got some new small apps (moving to SOA) and would like to try this
> > out.
> > cheers,
> > nahum
> > --
> > You received this message because you are subscribed to the Google Groups
> > "WellRailed" group.
> > To post to this group, send email to wellrailed@googlegroups.com.
> > To unsubscribe from this group, send email to
> > wellrailed+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/wellrailed?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "WellRailed" group.
> To post to this group, send email to wellrailed@googlegroups.com.
> To unsubscribe from this group, send email to
> wellrailed+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/wellrailed?hl=en.
If you have CI server already then adding deployment is usually just adding one more step to your build command. Let's say you have Hudson already setup and watching your development branch and your build command is like
> && ey deploy -e your_env_name_goes_here -m --branch development
"ey deploy" can be "cap deploy" or "git push heroku master" or whatever you use for deployment. Of course you need to setup SSH keys and everything else you may need.
I've tried this for staging environments only cause usually deployment to production may require scheduling with other teams (marketing , support. etc) but this depends on the app itself.
For monitoring we use New Relic, but I see people really love statsd for custom metrics.
On Thursday, August 16, 2012 10:03:13 AM UTC+3, nahum wrote:
> I've listened to that podcast already, it's pretty interesting.
> As we're building new apps we're requiring metrics just like we *cough* > require tests. Currently using Redis to track current state of the system > then using the below node lib to subscribe to keys and show live changes > via websockets.
>> Essentially they talk about having good metrics can be vital for going >> to a continuous deployment type setup. It's very helpful to have a >> graph you can watch after deploying and see: oh no, my errors per min >> is going up/response time is going down/whatever metric is important >> to your business is going down - I need to look into this.
>> Might be relevant and/or interesting.
>> -Malcolm
>> On Thu, Aug 16, 2012 at 4:39 PM, Nahum Wild <nahum...@gmail.com<javascript:>> >> wrote: >> > anyone do this? recommend any tools for it? tips of what not to do?
>> > we've got some new small apps (moving to SOA) and would like to try this >> > out.
>> > cheers, >> > nahum
>> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "WellRailed" group. >> > To post to this group, send email to wellr...@googlegroups.com<javascript:> >> . >> > To unsubscribe from this group, send email to >> > wellrailed+...@googlegroups.com <javascript:>. >> > For more options, visit this group at >> > http://groups.google.com/group/wellrailed?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "WellRailed" group. >> To post to this group, send email to wellr...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> wellrailed+...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/wellrailed?hl=en.
krasimir.ange...@gmail.com> wrote:
> If you have CI server already then adding deployment is usually just
> adding one more step to your build command. Let's say you have Hudson
> already setup and watching your development branch and your build command
> is like
> and you wanna deploy your app to EY (what's the case for us) if tests
> pass, then you just need to add that to build command:
> bundle install && bundle exec rake db:migrate db:test:prepare spec
>> cucumber && ey deploy -e your_env_name_goes_here -m --branch development
> "ey deploy" can be "cap deploy" or "git push heroku master" or whatever
> you use for deployment. Of course you need to setup SSH keys and everything
> else you may need.
> I've tried this for staging environments only cause usually deployment to
> production may require scheduling with other teams (marketing , support.
> etc) but this depends on the app itself.
> For monitoring we use New Relic, but I see people really love statsd for
> custom metrics.
> K.
> On Thursday, August 16, 2012 10:03:13 AM UTC+3, nahum wrote:
>> I've listened to that podcast already, it's pretty interesting.
>> As we're building new apps we're requiring metrics just like we *cough*
>> require tests. Currently using Redis to track current state of the system
>> then using the below node lib to subscribe to keys and show live changes
>> via websockets.
>>> Essentially they talk about having good metrics can be vital for going
>>> to a continuous deployment type setup. It's very helpful to have a
>>> graph you can watch after deploying and see: oh no, my errors per min
>>> is going up/response time is going down/whatever metric is important
>>> to your business is going down - I need to look into this.
>>> Might be relevant and/or interesting.
>>> -Malcolm
>>> On Thu, Aug 16, 2012 at 4:39 PM, Nahum Wild <nahum...@gmail.com> wrote:
>>> > anyone do this? recommend any tools for it? tips of what not to do?
>>> > we've got some new small apps (moving to SOA) and would like to try
>>> this
>>> > out.
>>> > cheers,
>>> > nahum
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "WellRailed" group.
>>> > To post to this group, send email to wellr...@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> > wellrailed+...@**googlegroups.com.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WellRailed" group.
>>> To post to this group, send email to wellr...@googlegroups.com.
>>> To unsubscribe from this group, send email to wellrailed+...@**
>>> googlegroups.com.
> To post to this group, send email to wellrailed@googlegroups.com.
> To unsubscribe from this group, send email to
> wellrailed+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/wellrailed?hl=en.
> in terms of monitoring I'd add scoutapp.com to your list.
> --nahum
> On Thu, Aug 16, 2012 at 8:40 PM, Krasimir Angelov <krasimir.ange...@gmail.com> wrote:
> If you have CI server already then adding deployment is usually just adding one more step to your build command. Let's say you have Hudson already setup and watching your development branch and your build command is like
> and you wanna deploy your app to EY (what's the case for us) if tests pass, then you just need to add that to build command:
> bundle install && bundle exec rake db:migrate db:test:prepare spec cucumber && ey deploy -e your_env_name_goes_here -m --branch development
> "ey deploy" can be "cap deploy" or "git push heroku master" or whatever you use for deployment. Of course you need to setup SSH keys and everything else you may need.
> I've tried this for staging environments only cause usually deployment to production may require scheduling with other teams (marketing , support. etc) but this depends on the app itself.
> For monitoring we use New Relic, but I see people really love statsd for custom metrics.
> K.
> On Thursday, August 16, 2012 10:03:13 AM UTC+3, nahum wrote:
> I've listened to that podcast already, it's pretty interesting.
> As we're building new apps we're requiring metrics just like we *cough* require tests. Currently using Redis to track current state of the system then using the below node lib to subscribe to keys and show live changes via websockets.
> Essentially they talk about having good metrics can be vital for going
> to a continuous deployment type setup. It's very helpful to have a
> graph you can watch after deploying and see: oh no, my errors per min
> is going up/response time is going down/whatever metric is important
> to your business is going down - I need to look into this.
> Might be relevant and/or interesting.
> -Malcolm
> On Thu, Aug 16, 2012 at 4:39 PM, Nahum Wild <nahum...@gmail.com> wrote:
> > anyone do this? recommend any tools for it? tips of what not to do?
> > we've got some new small apps (moving to SOA) and would like to try this
> > out.
> > cheers,
> > nahum
> > --
> > You received this message because you are subscribed to the Google Groups
> > "WellRailed" group.
> > To post to this group, send email to wellr...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > wellrailed+...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "WellRailed" group.
> To post to this group, send email to wellr...@googlegroups.com.
> To unsubscribe from this group, send email to wellrailed+...@googlegroups.com.
> To post to this group, send email to wellrailed@googlegroups.com.
> To unsubscribe from this group, send email to wellrailed+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "WellRailed" group.
> To post to this group, send email to wellrailed@googlegroups.com.
> To unsubscribe from this group, send email to wellrailed+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.