Skip to content

Instantly share code, notes, and snippets.

@loganmeetsworld
Created July 22, 2016 18:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save loganmeetsworld/941ea9c6f7a63646b3ccd91acaabe6e0 to your computer and use it in GitHub Desktop.
Save loganmeetsworld/941ea9c6f7a63646b3ccd91acaabe6e0 to your computer and use it in GitHub Desktop.

DevOps for the Uninitiated


( Me )

^ Because this is the role that I have been in, the uninitated


I am the uninitiated.


πŸ‘‹

logan

@loganmeeetsworld

logancodes.it

^ intern at Chef where we automate infrastructure ^ which just means we try to make tools that allow you to make tasks into code ^ I am about 10 months through the Ada Developers Academy ^ Early career SDE


[fit] Incorporating DevOps in

[fit] Personal Software Development


#πŸ€” -> πŸ’‘ -> πŸ’» -> πŸŽ‰ ^ My view of the development process throughout most of ada ^ Starting out this seems like what developers do ^ Think > Idea > Code > Profit (show people the awesome thing you built) ^ I mean this title to sound kind of weird because it's about how you develop software, how you are developing as a software engineer, and your voice/identiy in the career. ^ If you have a side project, big personal project, or want to embrace this more in work, this talk is for you.


#πŸ’» ??? πŸŽ‰ ^ But what about the space between code and Profit ^ We are talking about how we get through that last step. ^ Learned a lot about this last part of the process ^ It IS the process and is what we call Devops


"Devops is a way of thinking and a way of working. It is a framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways."

Effective DevOps

Jennifer Davis & Katherine Daniels

^ First sentence of first chapter of their book, sums up teams well ^ So this is what we are talking about when we say DevOps. Gets rid of a lot of the misconceptions about Devops being a job title ^ This talk concentrates more on how an individual can embrace this culture when working on their own project, rather than on teams. ^ How can I do DevOps without a huge Ops Team? ^ Devops as an 'advanced topic' ^ Devops as a 'specialized field' ^ No, Devops as a cultural movement


[fit]Devops is building out better habits.

[fit]Devops is having empathy for oneself.

[fit]Devops is building meaningful things.

[fit]Devops is doing more of what you love.

[fit]Devops is fun!

^ My definition ^ Constraint problems are super fun and the skills are meaningful ^ Devops is habits. Development is habits. ^ Understanding who future you is and why they are important ^ Automation makes things faster, allows you to build more of what you want


Lights on Washington

inline

^ My personal test case with this: Ada capstone process ^ Going from small apps to an app that had to host millions of rows ^ A lot of people in my cohort were thinking of deploying in the third or forth week ^ I knew I had to deploy earlier to stay on top of it so I learned a lot about the tools around continuous deployment


1. Communication πŸ—£

2. Continuous X πŸ”ƒ

3. Tools πŸ› 


Communication

^ VERSION CONTROL ^ Git commits: when you should commit? - ALWAYS ^ Git history is the story of your development and deployment process ^ The importance of keeping a great history ^ Make branches for specific features ^ Not a save button, but a history

^ DOCUMENTATION: ^ Docstrings ^ Get a linter and set it up to be mean to you ^ Write your code like you'd right an essay: thesis, support, edit

^ TEST DRIVEN DEVELOPMENT ^ Tell a narative, write a test that begs a question then answer it


##[

'Testing'

'Integration',

'Delivery',

'Deployment',

'πŸŽ‰'

##] ###.each { |item| puts 'Continuous ' + item }

^ Testing: Test throughout, TDD ^ For you: Actually writing tests for your CI to run ^ For you: having a good development environment that makes you successful which means having good command line tools, and a staging environment ^ Integration: Integrate new code into the master branch, contrast to having developers working independently on feature branches for weeks or months at a time ^ For you: merge branches often and set up a CI system to check those merges against tests ^ For you: setting up a staging environment of your choice ^ if it fails, fix it, if not it should be deployable ^ Delivery: principles allowing for frequent releases ^ For you: when you merge a branch that isn't WIP, they can be deployed ^ For you: knowing how to ssh onto nodes and troubleshoot, getting use to doing that in a Staging environment and then production ^ Deployment: Actually deploy it, and validate success/failure faster ^ For you: You can send your MVP to testers/users sooner rather than later ^ Tada: Get to have that great feeling of other people seeing your product and can do more of the things you love


Tools

^ I'm doing this because when I started out I heard Travis CI and Docker in the same sentence and thought that they'd be comparable in terms of learning curve... uh ... not true.


Command Line Tools

  • oh-my-zsh
  • dotfiles
  • Unix wizardry
  • Learn a built in command line editor

^ oh-my-zsh has great shells providing some autocomplete and aliases ^ people set up their shell preferences and make them open source on github ^ write down every command you put into your command line and look for patterns ^ learn how to not panic when you see built in command line editors, there is no text editor eruditeness here but it's helpful to know your way around one


Version Control

  • Git best practices: chris.beams.io/posts/git-commit/

* Travis Continuous Integration, travis-ci.org

^ Travis is easy to set up, open source, has great documentation, and will automatically run tests against a specific branch (usually master) ^ Travis is one of the easiest tools out there ^ Syncs right into your Git stuff


Terraform or Test Kitchen

  • Build AWS infrastructure sandboxes

* Learn about configuration
* Debug executing that configuration
* View code in a production-like environment

^ Learn about building a production-like environment ^ Learn about setting up configuration files and then executing them and then inevitably debugging them ^ Use Terraform to ^ Use Test Kitchen with Chef and Vagrant (or AWS) to quickly spin up a system


Containers

  • Feel cool

* Try it out in Development
* Learn how to configure dockerfiles
* Docker allows you to get setup in development fast

^ Way of sandboxing the code that runs in them and have less overhead and depedence on operating systems than virual machines ^ Run containers of things that usually take you a while to run/setup and just type these words and get all your stuff running: your database, Redis, etc.


Chef Recipes

  • Automate setting up a workstation

* Learn configuration management
* Learn infrastructure as code

^ This is where writing down all those CLI commands will come in handy ^ Instead of running the same shell commands by hand on every server, put these into scripts that can be executed by themselves


πŸ’» -> πŸ€” -> πŸŽ‰

^ If we put more effort into this part, we can save our selves time, learn a lot, and get more tada ^ Will make you great to have at a company - you'll be more empathetic, you'll understand real world tools


πŸ‘‹

logan

@loganmeeetsworld

ask me questions over there ➑

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment