One of the reasons that DevOps can be transformative to an organization is that it shortens feedback loops - talking about CAMS, the measurement piece is where that can come into play. Anyway, in that spirit, we’re taking feedback we’ve gotten from listeners who want more detailed, technical topics, and we have an episode talking about the HOW with git - with a very special guest, Emma Jane Westby.
Microsoft is open-sourcing .NET and creating the CLR for Mac and Linux .Net core5 is the new framework for 5, you can ship your own version of the app.
There is now a free version of Visual Studio — Visual Studio Community for open source developers and students. In fact, it is all happening out in the open on github.
Emma Jane is a long time listener of ADO! She has been teaching version control for many years with specific emphasis on the communication behind version control in teams. She has since switched to distributed version control such as git. Her aim in her teachings is to create resources that make git ”less painful” than it currently is.
Distributed vs Centralized Version Control
Emma Jane:
- In distributed VC the DB that contains the changes, exists on the local system and I can have multiple connections to multiple DBs with other versions.
- Centralized is all in a single DB, locally.
How is Distributed VC relevant to DevOps?
Matt: Many people hold the theory that you cannot have “The DevOps” without distributed version control. It implies communication through teams, so what is the validity of that statement.
Emma Jane:
- Git is not the only VC option out there, but it is the most popular currently.
- You need to assess your team and your project, along with the related expertise and community support, and go with the one that fits your needs.
- As soon as you say “can’t” someone will prove you wrong.
Testing
Matt:
- The whole basis of git-flow is based on the fact that you can’t trust your contributors. Especially with open source. It sends a message that says “I don’t have to test my shit, because you’ll do it for me.”
Emma Jane:
- If we are talking about testing, you need to have full coverage testing of whatever your product. Many testing frameworks allows for 99.9% accuracy on the tests, but that .1% causes you not to trust your tests. This makes it really hard to get reliable CI into the dev process.
- For that matter, Devs shouldn’t trust themselves when it comes to pushing code, you should always rely on testing because everyone is going to make mistakes, and humans might not catch them.
- Git allows you to have control over the pushed code.
Trevor:
- There should be no permissions. All developers should have the same permissions and the flow should go through QA.
How do you learn git?
Emma Jane:
-
All kinds of people are interested in learning git. But mainly:
- Someone who is on subversion and wants to change to git
- Someone who has been told to use git, but they don’t know how to run command line tools.
- CTO or management types that know they want to use git, but they’re not really sure where to go from that decision.
-
In order to identify how your team will most efficiently use git, draw out your team flow and identify where efficiency is being blocked. Is re-basing causing problems? Is a PR sitting out there for too long? Use those as discussion points with your coworkers.
-
You cannot introduce creativity when you are just told to memorize commands.
Emma Jane: - Use Interactive Add! It allows you to split up your diffs into different commits. So you don’t end up committing a huge chunk of features that should most-definitely not be committed together.
How do I get set up?
Look for the right git-flow based on the type of deployments you are going to be using to release the software. Are your deployments feature based? or time based? How important is a rollback?
Your code should always be deployable in a CD framework. You are only rolling forward, you have one master branch, and feature branches, how can you have correct and fast CD if you have multiple branches before the CD process starts.
Your git setup should be directly related to your infrastructure. The git releases and flows of a team of 1 is going to be massively different than the git flow of a large team for a Could Provider.
Things you should know (about git):
Rebasing:
- Rebasing allows you to recombine how your commit chunks are strung together. It takes all the commits of a branch and
- Great for when you are adding too many commits.
Git Bisect
- You can take out commits individually, and assess if the commits are in a working state.
- However, if you do not have full commits, for example, commits when you are just thinking about something, it will be much harder to assess the state of the commits individually.
Source of Emma’s talk about Git: http://github.com/emmajane/gitforteams Post version: http://24ways.org/2013/git-for-grownups/ Recording: http://prague2013.drupal.org/session/git-makes-me-angry-inside
Emma’s rant about storing the history of your project: http://gitforteams.com/resources/evolution-social-coding.html
GitHub conversations: http://guides.github.com/introduction/flow/
Check-outs
Emma- Kaleidoscope mergetool - because of image diffs
- Sketch training for techies - because of impostor syndrome for drawing
- GNOME wins - go open source!
- Teamocil - generator for tmux sessions
- The NoPhone - kickstarter for a “technology-free alternative to constant hand-to-phone contact”
- “It’s not a promotion, it’s a career change” - blog post by Lindsay Holmwood
- Sandisk SSD
- Android L: Inbox
- Rosetta Probe
