Reddit mentions of Continuous Integration: Improving Software Quality and Reducing Risk (Martin Fowler Signature Books)

Hi and sorry for the late reply! The first thing I'll have to ask is what environment are you deploying into, a manually configured virtual machine/bare-metal machine, Heroku, Ninefold? Each of these environments have different (sometimes vastly different) considerations when it comes to deployment of any application. In general though, here's some things that will apply that will apply to any good deployment process (some of what's below echoes /u/codekitten's reply):

• Remove ALL credentials from your codebase: I can't stress this enough, and even for a simple project it's a good habit to get into early on. It's been enough of an issue that there are even dedicated tools to help people remove hard-coded credentials from their codebases. A good resource to explain both this, as well as the general concept of storing environment-specific configuration data outside of your codebase is this section of the Twelve-Factor App website. Personally, aside from things like tokens that Rails uses internally like Rails.application.config.secret_key_base, I will always use environment variables coupled with something like dotenv or direnv to also manage the configuration for my local development environment.
  
• SSL and HSTS: IMHO there is no (good) excuse nowadays to serve a web application over HTTP. Once again, even for simple projects it's a good habit to get into and a good thing to learn. If you're hosting your application on Heroku, all Heroku application subdomains (i.e. rxsharp.herokuapp.com) will respond to HTTPS, but it's up to you to ensure your user's will always use SSL. Rails has the force_ssl setting to do this automatically for you, which you should have turned on in all of your production and production-like environments, but you should also be using HSTS to ensure that your users always visit your site over SSL (force_ssl performs a permanent redirect to https://rxsharp.herokuapp.com but does not set the HSTS headers). The gem that I use most often to take care of setting these headers for me is secureheaders, which also helps you configure a number of other security headers like Content Security Policy headers.
  
• Continuous Integration: Let me expand a bit on /u/codekitten's item for passing tests to say that you should have a system in place that will automatically run all of your tests each time you push to your repository and holds you accountable when things break. Continuous integration is a huge topic that I won't dig too much into here, so I'll just point you two two indispensable books on the subject: Continuous Integration: Improving Software Quality and Reducing Risk, and Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Conceptually, you will learn almost everything you need to get started and thensome on the topic from those two books. Once you get your CI configuration in place, you will get in the wonderful habit of always making sure your build passes locally before you push to your repository. A good CI script will:
  
  • Run static analysis tools like RuboCop and Brakeman
    
  • Run all of tests
    
  • Notify you when a build fails and when it gets fixed
    
• Automate Everything: One of the most important things to learn about deployment early on is automation. Apart from initiating the deploy (and arguably even initiating the deploy itself), everything about your deployments should be automated to the fullest extent. There are several tools in the Rails world that most people use to accomplish this, most notably Capistrano and Mina. If you are using a platform-as-a-service like Heroku or Ninefold, see the documentation for one of those on how to automate various aspects of your deployment process.
  
• Deployment Smoke Testing: In my experience working in the Rails world, it seems that not a lot of people automate their post-deployment verification, even though it's very easy to do! It can be as simple as having a post-deployment hook that uses curl to hit a status page on your site that returns the currently deployed revision, and rollback the deploy if it receives an error. It can also be as complex as running a suite of RSpec examples that utilize something like Serverspec to assert the state of each one of your application servers (obviously this one doesn't work as easily in environments like Heroku). In the end, the important things here is that you automate EVERYTHING when it comes to your deployments.
  
• Database Migrations: First of all, don't forget to run them! If you're using something like Capistrano to script your deployments, the command to run a deployment that includes a database migration is cap production deploy:migrations, not cap production deploy. On Heroku, you need to run them manually after you deploy using something like heroku run rake db:migrate. One further topic here that I highly recommend you explore is that of zero-downtime migrations. A great introductory article on these is Rails Migrations with Zero Downtime over at Codeship.
  
  These things are all general items that belong near the top of any checklist for deployment (Rails or otherwise). Hope this helps!

Ha! Well I was thinking more along the lines of a company (or programming department) handing out a book that might intimate that they cared about the right things. Like, to pick one kind of at random, Continuous Integration: Improving Software Quality and Reducing Risk.

/u/lordv0ldemort I would recommend:

https://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380

https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

>How did you get started in DevOps?

I watched https://www.youtube.com/watch?v=LdOe18KhtT4. I realised this was the future and if you wanted to be in a high performing organisation you need to do what they're doing.

Unless you're in an organisation that is willing to undergo the cultural change of Operations and Development working together you're probably not going to go far. Creating a devops organisation from scratch is HARD unless everyone is on board.

Looking into the technology is the simple part, try reading around the movement. Pheonix Project (http://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509) is a good start, from there I'd look into Continuous Integration and Continuous Delivery (https://www.amazon.co.uk/Continuous-Integration-Improving-Software-Signature/dp/0321336380 & https://www.amazon.co.uk/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912).

If by this point you don't know a programming language you're going to be in serious trouble. Learn something, be it Powershell (and honestly you probably will want to move onto C# if you want to be amazing at what you) or Python/Ruby.

Honestly you should be working towards what Google does with SRE if you want to be at the leading edge. https://www.amazon.co.uk/Site-Reliability-Engineering-Production-Systems/dp/149192912X.

> You are right, there is no such thing as classful design. It is called Object Oriented Programming.

Object oriented programming isn't what the web acts like it is. It's two different small, simple things, depending on which crowd you ask.

The original crowd wanted it to be asynchronous unguaranteed messaging to interfaces. You see systems like that in Objective C, Erlang and Smalltalk.

Bjarne learned it in Smalltalk and wanted something like that with compile time safety and efficiency, so he made C with Classes, which became C++. Because C++ became so visible, most people in the era learned OOP from C++, and therefore the world was given what most people think OOP is, the C++ model.

Mind you I'm not criticizing that. I prefer it to the original.

The points are varied:

1. They're two very, very different things.
   
   
2. Neither of them are particularly important. They're convenient, and in some cases can help you avoid some classes of error, but all things equal, if they disappeared from history, we wouldn't be all that much the worse for it. I do a fair amount of OOP, don't get me wrong; I'm not saying it's a bad tool. I'm just saying it's not a particularly big deal; it's convenient and it's easy. People who are deeply fascinated with it are usually either rank amateurs with golden hammer syndrome or language designers looking to change how it works.
   
   
3. What you probably think of as object orientation isn't even normative. There's a third kind - prototypical orientation - available in JavaScript, ActionScript, et cetera. There's a fourth kind - declarative typing - available in Mozart, ADT, Coq, and I think maybe OcaML or Eiffel or maybe Haskell. Then there's all the ML stuff and the ... I'm not even getting into haskell, thanks. Pain in the ass language. There are class systems in cross-language loader interfaces like COM, CORBA, etc. There's a good argument for calling .DLL and .so class systems, or maybe even kernel modules and blah blah.
   
   > I do not think I was trying to be clever.
   
   You're trying to make a class and use autoloading to get around require_once().
   
   That is the definition of unnecessary cleverness.
   
   Just remember one thing and you'll be fine. Cleverness is where almost all of your difficult bugs come from. If you want to be clever, do, but it comes with a cost; you should use it sparingly, and always have A Good Reason (tm).
   
   Just fucking require a require list.
   
   > am just trying to design a system correctly.
   
   The first steps, in being an amateur, of designing a system correctly do not come in the form of trying to get around basic system affordances.
   
   Do you have a project specification yet?
   
   Do you have a functional specification yet?
   
   Is your timeline realistic?
   
   Do you have a deploy scenario? A deploy environment? A testing environment?
   
   > I want to build something that is easily maintainable and configurable.
   
   Then say that.
   
   http://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380
   
   > The tone of the response almost made asking the question not worth it.
   
   Then you're in the wrong line of work. There are two echelons in this occupation: the meritocratic group where every "do it right" is a learning opportunity to be appreciated, or the "you didn't have to say it like that" types who don't get help a second time and end up maintaining web pages for a living.
   
   > Here is a picture of how I felt after reading your response.
   >
   > http://i.imgur.com/ho9O4.png
   
   That's the purpose. That way you won't make this mistake again.
   
   Software development is critically sensitive to Doing It Right in a way that almost no other field is; when you combine that with the sheer amount of logic and complexity we face, about the only peers we actually have in terms of the criticality of non-failure are doctors, mathematicians and life-critical engineers, and even then mostly only in the extreme cases. And even in those cases, the only people who deal with the sheer volume of trivia we do are medical doctors.
   
   We don't tolerate failure for one very simple reason: we cannot. What you are receiving is not a shame or an insult. It's a gift phrased in the only way that'll make it stick fast enough that it'll matter.
   
   Software is a meritocratic occupation by demand. You either look at that as "holy shit, i fucked up, thank you" or you take umbrage and say "maybe it's not worth it."
   
   If you're the latter class, it isn't, because if you aren't a self-oriented perfectionist, you can't climb very high in this line of work.
   
   Real engineers believe every fault belongs to them. RAND has a fairly famous story in their basic training, which is given from everyone from the CEO to the janitor. Really, the janitor gets two weeks of mindset training, just like everyone else, and it's been shown to pay out.
   
   One of their very important ones is about a guy from one of the Los Alamos testing sites who bracketted a wing brace on upside down. The result was that the wing fell off in flight, and several tens of millions of hardware were unnecessarily destroyed.
   
   Most places someone would get fired for that. At RAND, it was officially not the grunt's fault, for specific reason, and a manager got promoted over it.
   
   What?
   
   No, seriously. What happened was the guy's manager came in and said "wtf, you're triple-fired yesterday." That manager's manager came in and said "well slow down, what happened?"
   
   The engineers there were following standard practice at the time: if you have four bolts, put them on in a rectangle, because that's the most rigid basic arrangement available.
   
   This second tier manager took RAND philosophy to heart: "if a problem happens, it is the fault of the process. Change the process to make the problem impossible."
   
   So he mandated that one of the bolts be offset from the rectangle in every design his team produced. This meant that bolting arrangements were 5-10% weaker on average. However, this also meant that it wasn't physically possible to put them on wrong. RAND had to use slightly heavier duty bolts to compensate, which are slightly more expensive, but eliminated an enormous class of error in response, saving them anusloads of money.
   
   And then the second tier manager fired the first tier manager for almost throwing away a very valuable learning opportunity because he was angry at a big money loss and needed to scapegoat some grunt who was following an imperfect process to the best of his ability, and whereas grunts do their job, managers are expected to understand the process, and RAND was structured specifically to prevent that.
   
   And that's why RAND makes so very fucking much money: their shit always succeeds, because in a very serious sense, there are no faults there, only learning opportunities. That sounds like glib bullshit, but if you stick to it, you get a very different outlook on life and projects and how hard-asses respond to you.
   
   Why?
   
   Because they're expressing annoyance that you missed one, and treating you like you should hold yourself to a higher standard.
   
   Why?
   
   Because it's the only way you'll succeed. I'm not being mean to you, and neither were your professors. This profession is a meritocratic austerity for a reason: because it's the only way you'll ever succeed.
   
   We're trying to give you the way of the samurai. Stop being so god damned butthurt, accept that a learning opportunity is worth any amount of egg on your face, and stop being so whiny in your thank yous.
   
   > None the less, thank you for it.
   
   You're welcome.
   
   ----
   
   TL;DR: would you want me to not break your arm to re-set the bones, if it had set wrong, just because it hurt?