A DevOps Story
•Als PPTX, PDF herunterladen•
0 gefällt mir•176 views
This story begins on a warm day in the summer of 2014. A new team was formed to work on a critical business application. That application had few releases a year and a mile long backlog that wasn’t getting completed. Two years later, that team was has had more than 300 releases in a year.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
A DevOps Story
- 2. • Team Size • Three engineers Year Software Deployments New Apps Released 2012 ~3 1 2013 ~3 0
- 4. John Chase
- 5. In case of fire 1 git commit 2 git push 3 leave building by Marco Leong
- 6. • Team Size • Three engineers Year Software Deployments New Apps Released 2012 ~3 1 2013 ~3 0 2014 ~10 0
- 7. 1. Do you source control? 2. Can you make a build in one step? 3. Do you make daily builds? 4. Do you have a bug database? 5. Do you fix bugs before writing new code? 6. Do you have an up-to-date schedule? 7. Do you have a spec? 8. Do programmers have quiet working conditions? 9. Do you use the best tools money can buy? 10. Do you have testers? 11. Do new candidates write code during their interview? 12. Do you do hallway usability testing?
- 8. Using a Hudson Bay approach to projects. Working more closely with the operations team. Goal was to release software every two weeks. Automation
- 10. GNU Make
- 11. Deployment without manual configuration Deployed from local system
- 13. • Team Size • Two engineers • One SQL Developer • One Contractor Year Software Deployments New Apps Released 2014 ~10 0 2015 ~50 1
- 16. • Team Size • Two engineers • One SQL Developer • One Contractor Year Software Deployments New Apps Released 2014 ~10 0 2015 ~50 1 2016 ~300 7
Hinweis der Redaktion
- Make sure to break the ice with that tester joke or something. Also don’t forget to talk about a theme that appears to see if any one gets it.
- Source control was a mess, it didn’t reflect production. Deployments consisted of only updated individual dlls. Developer time was spent fixing errors in data to keep the app from crashing. The app wouldn’t build except on one developer machine. Tons of memory leaks lead development team to create a time to measure ram and restart the app.
- So sometimes you just have to crawl through the mud and get back to basics. Are you using Source Control? Do you have a process like gitflow? Can you do a check out and build of your project on a fresh PC? Do you have a document that instructs how to configure a development environment, like tools, path variables etc.
- Setting up repeatable process for the team and picking and/or making standards. Picking work flows that work for the team, how build works, how source control is used, code reviews, tests, pair programming.
- Start using source control, pick a source control process like GitFlow. Environment configuration was added to the repo. Source was verified to match production. Talk about how I had to track down dependencies and moved the project to use Nuget as much as possible.
- So after getting just a few of the fundamentals straightened out and working you can see that we starting to gain momentum. We had done more releases than the previous two years combined. Source control reflected production, less bugs were coming in, and anyone could check it out and do a build using visual studio. The database was getting indexed and maintenance performed. Queries were optimized, more than a minute to less than 20s for a customer query. Memory usage per instance of the application was down 1GB and it was no longer leaking memory. Lead into the Joel test, talk about seeing something familiar, if not now you have seen it.
- Talk about the first five, really focus here. Have a discussion? Ask the crowd questions? See how many do the first five.
- Talking about Hudson bay starts Getting more Ops in our development
- Now that we have good source control one step builds and automated build you can start thinking about how to deploy your code in one step. You need to decide about deployment formats. If .NET web deploy, nugget packages, chocolately packages, installers. There are things like gems, pip packages, node modules.
- Can I check the code out after following setup and build it? Now it builds can you repeat it reliably. Great now you have documentation and the ability to easily create a build server. Again in my opinion your build should be in source control so using a build tool like Cake or fake makes that easier if you can just roll with MSBuild and a scrpt. But it should be in source control
- Now that you have a build script it is now time to automate. Lots of build server we started off using teamcity then migrated to Jenkins to be more aligned across the company. Alignment is important and helps foster learning.
- Use Jenkins files documents build server config
- Team wasn’t complete until July 2015.
- We had decided we where going to deploy using cloud services. Reduced load on our ops team and gave us the flexibility that we needed. Most cloud services have defined deployment processes, especially for PaaS so that took that out of the equation.
- So talking about having certain cloud services that are PaaS based reduces Ops overhead so you can move at a faster base and not overload your operations team, especially in lean orgs. Discuss the different choices we made and why.
- Now I need to wrap it up. Talk about desired state configuration, taking these practices to the whole organization. You can drive almost all IT from source control and deployment pipelines. I like this quote from an episode of RunAsRadio. If you try to go straight to thinks like docker etc without good fundementals, it is more than likely going to eat your lunch. There is a lot to manage, but if you follow having good habits, then you don’t have much to worry about.