^ Because this is the role that I have been in, the uninitated
^ 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
#π€ -> π‘ -> π» -> π ^ 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."
^ 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
^ 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
^ 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
^ 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
##[
##] ###.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
^ 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.
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
- 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
- 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
- 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.
- 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