search

smashingboxes / box_cutter

Box Cutter is inspired by thoughtbot's Suspenders. Just like Suspenders says, use Box Cutter if you're in a rush to build something amazing; don't use it if you like missing deadlines.
MIT License
4 stars 2 forks source link

Chef and Capistrano #16

Open reedlaw opened 10 years ago

reedlaw commented 10 years ago

The README leaves this as a question, so I'd like to start a discussion on what we should do so I can start pull requests.

I'm in favor of Chef plus Capistrano because they both have been around long enough so that they just workTM. There are community cookbooks for Chef that make provisioning a breeze. Ansible may be easier to understand, but Chef packs the power that can be unleashed in the rare event that an app actually needs it. Chef excells at provisioning and Capistrano at deployment, thus choosing both is choosing the right tool for the right job.

That said, do we also want to incorporate Vagrant for local setup? I'm using the vagrant-aws plugin and it makes working with AWS easy. Personally I don't need the VM provisioning support from Vagrant because I don't run apps on VMs locally. Some Windows or Mac devs may want that, especially for apps with lots of dependencies.

I'm also using the librarian-chef gem which makes it easy to install/update cookbooks.

BrandonMathis commented 10 years ago

The recent lunch and learn really has me convinced that docker would be a great tool to investigate for our deploy process. I'm not 100% sure if it replaces Capistrano completely but I would really like to have a conversation that includes Docker as an option if everyone is up to it :grinning:

cwjenkins commented 10 years ago

I second further research on docker. Here is a blog post that helps a bit. http://blog.leanstack.io/how-docker-fits-into-the-current-devops-landscape

Capistrano should be replaced with mina. http://nadarei.co/mina/

reedlaw commented 10 years ago

I'm all for new tools that make our lives easier or solve the same problems more elegantly. Docker and Mina may be such solutions, but it takes lots of dedication to adopt new devops tools. Does anyone have lots of time dedicated to devops and want to use their project as a pilot program for these technologies? There should be some measurable improvement over existing tools to justify the switch. Are deploys faster? Is productivity higher?

cwjenkins commented 10 years ago

I completely agree we should research tools prior to adopting. I wouldn't use a client's project as a test bed for a new feature though. I've found that doesn't typically work well for either party involved. ActualId is a perfect example.

I've used mina before on a previous project and I can personally say it is much faster than capistrano. The following link has a benchmark in which reflects my experience. https://weluse.de/blog/capistrano-is-dead-use-mina.html Its DSL is practically identical to capistrano's so little change is required. I plan on doing just that for the next Lab. https://www.codemy.net/posts/dofd-episode-12-mina-for-deployment

reedlaw commented 10 years ago

In defence of ActualID, we spent weeks hashing out UML-like diagrams of ActiveRecord models on whiteboards, and still we couldn't come up with a solution to handle all the edge cases. I had been learning about Clean Architecture as well as working on more traditional OO design for a C++ project in my spare time. I thought it would be worth trying to model the app using only POROs and see how far I could get. Before long (maybe a week) I had a system working with lots of test coverage. Then we worked to integrate this domain logic into the existing Rails app. The problems you see are not related to experimentation so much as to extremely tight schedules at the beginning that lead to time crunches and technical debt. We're still paying off that technical debt but I truly feel that switching to the unconventional design saved the project. Of course if we were to do it all over again we could probably come up with even better solutions. I'm thinking Functional programming might be a good fit for this application. But I still can't imagine how it could be done the Rails way. Despite DHH's rhetoric, Rails is not always the best tool for every job.

Back to testing new tools, if we shouldn't use new tools in clients' projects then we're pretty low on options. SB.com? It can only test so much. The dilemma between needing to test new tools and not wanting to mess up client work leads me to conclude that we need a 3rd option. That is, we need a dedicated DevOps Program within Smashing Boxes. By "Program" I mean something that doesn't end, unlike projects. Each project has its own constraints and requirements so we can't simply piggyback DevOps work on top of each project and expect it to turn out OK. In practice, we often have zero hours budgeted for DevOps (like with Actual ID). So we need an ongoing effort with hours allocated to working spefically on sharpening our tools and improving our infrastructure. To cover those hours, Brian may have to charge a higher hourly rate, but it should be a win-win because clients will benefit from the know-how we've accumulated across all our projects as well as the research and improvements brought about through the dedicated devops program.