All Around Azure: DevOps with GitHub - Managing the Flow of Work
•Télécharger en tant que PPTX, PDF•
0 j'aime•154 vues
Let's see how to use GitHub and Azure DevOps together to manage the flow of work. DevOps is all about continuously delivering value. Before we can even begin thinking about CI/CD, we need to make sure we do the right work. Sprint after sprint, iteration after iteration, we need to plan our work and manage our workflows. This includes planning and tracking all units of work for the project. With frequent small iterations, there is no time to waste. Careful planning needs to happen to ensure the correct work gets done for each iteration. With the compressed time frame for each iteration, team members must work and coordinate their activities. Thus cross (functional) team visibility of work becomes vital for that coordination and allocation of resources. Visibility also ensures problems or bottlenecks get surfaced and addressed quickly.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à All Around Azure: DevOps with GitHub - Managing the Flow of Work
Similaire à All Around Azure: DevOps with GitHub - Managing the Flow of Work (20)
Plus de Davide Benvegnù
Plus de Davide Benvegnù (20)
Dernier
Dernier (20)
All Around Azure: DevOps with GitHub - Managing the Flow of Work
- 1. DevOps In Azure: Managing the Flow of Work D A V I D E B E N V E G N U D E V O P S A R C H I T E C T @ D A V I D E B E N V E G N U
- 3. DevOps is the union of People, Process, and Products to enable continuous delivery of value to our end users
- 4. DevOps: The Three Stage Conversation Process Products People 2 3 1
- 5. Process Plan Develop Deliver Operate Development Production Enablement marketing development process 2 3 4 1
- 6. Scrum Inputs from Executives Team, Stakeholders, Customers, Users Finished Work Sprint Review Sprint Retrospective Sprint Planning Meeting Product Backlog Product Owner The Team Ranked list of what is required: features stories,… Team selects starting at top as much as it can commit to deliver by end of Sprint Task Breakout Sprint end date and team deliverable do not change Sprint Backlog Scrum Master Burndown/up Charts Every 24 Hours 1-4 Week Sprint Daily Scrum Meeting The Agile: Scrum Framework at a glance
- 7. General Principles • Product is built incrementally • Frequent inspection and adaption (course correction) • Transparency (Product and Sprint backlogs are public) • Product Owner, Development Team, Scrum Master • Scrum Teams are self-organizing and cross-functional
- 8. Never skip the rituals • Educate everyone on the purpose of the meetings • Never go over the time box • Running these meetings is a skill you must develop
- 9. Estimates Never accept an estimate over 4 hours • More accurate • Enables parallel development • Confirms alignment with DoD Never start from a date
- 10. The Rules Apply to Everyone No one is above the law Even the CEO must obey the rules
- 11. Demo Tracking Work using Azure Boards
- 13. Thank you
Notes de l'éditeur
- Thanks Aaron Let’s see how to properly manage the flow of work using Agile, DevOps and the tools provided by Azure DevOps and GitHub.
- So, Tailwind Traders has gone all-in in DevOps. They’ve read about it, they’ve studied it. They’ve gone to classes on DevOps. They 100% believe this is the way going forward for them. And they have even decided on their tooling stack. Now, they are ready to start doing DevOps. But.. What does that mean…
- What exactly is DevOps? If you ask 10 different people, you‘re going to get 10 different answers. Someone thinks it’s just a job title, someone else that is about automation, you name it.
- For us, DevOps is about value. Because delivering value is the most important part of any product or service, and the earlier you can put something in the hands of your users, the sooner you can evaluate its true value. That’s why we’re after “continuous delivery” at MS.
- But it’s not easy to do this right. In order to really adopt DevOps best practices, you must address all its three pillars. The people, the process and the products. About the people, that’s a cultural change that must occur within your organization. Where every person from the very top all the way to the bottom must be all hyper focused and aligned on continuously delivering value. For process, we need a process that will let us iterate fast enough, yet still deliver quality code. And finally, we need products that help enable all of this. Well, at Tailwind Traders, they’ve got the people and culture down. Everyone is now aligned and believes in DevOps and everyone is prepared to do whatever it takes to continuously deliver value. They’ve even got their products and tools down as you saw in the previous session. So all they need now is the process.
- We have to design a process that allows Tailwind Traders to innovate fast, yet still deliver code of high quality. It needs to be highly iterative, because they wanna have many frequent small releases, so they can deliver value faster and react quickly if anything is wrong or doesn’t work as expected. Devs need to check code in and out of a central location. And of course there is a need to be able to track changes of other devs This process has to include Builds, which need to kick off automatically, and security scans need to be automated as well If builds succeed, Continuous Delivery needs to package their app for deployment. Does this sound kinda familiar? What kind of process can do this for us? The answer is Agile, in one of its many forms.
- Well, I personally like SCRUM, and we use a SCRUM-like approach even within MS and GH. Don’t get me wrong, other Agile approaches and methodologies are good too and they work. But today we are gonna look at SCRUM. So.. in SCRUM, everything starts with a backlog. Think of it as a prioritized list of everything you want your software to do. The most important things are on top, the least important sink to the bottom. At the beginning of a sprint (or iteration), the product owner prioritizes that backlog. And then the team commits to doing part of that backlog based on priority and what they think they can get done, they form the Spring Backlog in the Sprint Planning Meeting. They spend the sprint working, they fix any bug found, and at the end of the sprint they show what they’ve accomplished to the product owner in a Sprint Review meeting and hopefully, they push to prod. And based on the sprint review demo, the Product Owner then reprioritizes the backlog and the whole cycle starts again.
- Now, that was a super quick description of Scrum, so let’s dive in a little deeper on some of the general principles of Scrum. As we’ve said, we don’t build the entire application and then release it. We build it up incrementally, sprint after sprint, focusing on the highest priority items on the backlog first. And we do this because this allows for immediate feedback. This is SUPER important. Most of the time, people don’t really know what they want their software to do until they start using it, or anyway requirements and needs changes overtime. By building our software incrementally, we can have frequent inspections of the software and immediately correct as needed. Instead of wasting months of work, the worst that could happen is we waste one iteration, which is usually 2 weeks. This is often a game changer. Next, in an Agile or Scrum project, EVERYTHING should be transparent. The dev team is not working in isolation. The product and sprint backlogs should be public where everyone can easily see what the team is currently working on and what the team will most likely work on next. Transparency and communication are key. Next I want to touch on what makes up a scrum team. There are really only 3 roles. There is the Product Owner, who is prioritizing the backlog. That’s basically all that role does. The first thing I tell new product owners is that this is not a waterfall project. We do not ship when everything is finished. In fact, most likely, we won't ever get to a point where everything on the backlog is finished. Hopefully, we will be shipping every sprint, so we need to make sure the most important features are prioritized so they get done first. Prioritization and the course corrections that come from re-prioritizations are so important. Next, there is the Scrum Master. The scrum master has 2 roles. 1) to make sure the team follows scrum best practices and 2) protect the scrum team from outside interference. It may happen to get some exec walking up to a dev and tell them, “I need you to add this feature immediately!”. This messes everything up and it is the scrum master’s job to protect their team from this. They need to tell that exec, NOPE. You can’t drop something on mid sprint. Put it on the backlog, rank it really high and we can tackle it next sprint! Finally, there’s the dev team. This team should be cross functional. Meaning that there is someone on your team that can do whatever you need to for your project. The more cross functional the better. Last but not least, these scrum teams should also be self-organizing. No one needs to direct a scrum team on how to do what they need to do. They will figure that out for themselves.
- Another important thing in SCRUM are the rituals. You can not skip ANY of the rituals or meetings. And anyway there are only 4 required meetings per sprint. Sprint Planning – Where the Product owner prioritizes that backlog and the team commits to what they will do for that sprint. Daily Standup – where the dev team discuss on 3 and ONLY 3 thongs. 1) what did I do yesterday, 2) what I’m planning on doing today and 3) any blockers?. The daily standup needs be less than 15’ always. Sprint Review – At the end of the sprint, the team demos what they have done to the product owner who gives feedback Sprint Retrospective – Where the team breaks down the good, the bad and the ugly of what happened during the sprint. If anything bad happened, they should also come up with plans on mitigating those things. These meetings are VITAL for scrum to run smoothly, this is wjy they must all happen. But remember to never go over the time box. We don’t want to be wasting any time, so the scrum master has to run the meeting very efficiently!
- Let’s talk for a moment about Estimates. First think, remember that estimates are NOT guaranteed… Although the more you do them, the more accurate you can usually get. To help with your estimates, here are some general guidelines. Most work should be broken down to 4 hour chunks. Why 4 hours? First of all, it’s a lot more accurate. Most people are pretty good at estimating things within 4 hours. At most a day (8 hours). If you go longer than that, chances are you are just guessing. Next, if we break down a user story into 4 hour tasks, there is now a real possibility that this can be split up into multiple small tasks that the team can work on in parallel. And this means we can complete this user story much faster. Also, if we break all of our user stories down into small tasks, just by looking at the task board I can quickly see if we are all in agreement on what Done means. Done to me means the user story is implemented AND unit tests are written. Now, if I don’t see unit test tasks assigned to a user story, as the Scrum Master, I can quickly point this out and the dev can now be aligned correctly on what our Definition of Done is. And finally, NEVER START FROM A DATE. If you start from a date, we as developers will magically subdivide up the work to fit the allotted time. Even though this doesn’t work and isn’t accurate, it is what we do. So don’t start from a date. Work out the tasks in 4 hour chunks instead, and then see where the end date lands. Get good and real estimates. Not what you want them to turn out.
- And finally, before we move to the demo, remember that the rules apply to EVERYONE! In order for agile to work, everyone in the organization must be focused and aligned. Remember, the whole point of moving away from waterfall to agile is we have finally admitted that waterfall does not work well in software development. 90% of software projects fail. And by fail I mean they go over budget, over time, too many bugs or the end result is not what the end users want. We must ALL be aligned with how things are done and measured in Agile. Everyone. From the very top of your organization all the way down to junior intern from college. NO ONE IS EXEMPT from the rules no matter what their title is. This is very important!
- Ok, so now, Tailwind Traders gets DevOps and they get Scrum. But to do it right they need tools that will help them track their work from sprint to sprint and they need to be able to easily reprioritize work on the backlog as well as track their work within the sprint. Well, this is where Azure Boards linked to a GitHub repo does a great job. Let’s see this in action. -------- Backlog, adding work, reprioritizing work Add work to sprint Show sprint backlog Sprint breakdown Taskboard for sprint Kanban board GH/AB integration checkin
- In the world of agile or scrum everything starts from your backlog. So here is your backlog; as you can see it's an ordered list of everything that I want my software to do. Adding new work is super easy: just click the "New work" button, give it a title, and there you go, it's already been added. I can click on the work item itself to open up the form and I can give this work item more details. I can add description, acceptance criteria, etc etc. If I want to prioritize my backlog, it's as easy as dragging and dropping a work item. The other thing people use backlogs for is choose the task from the backlog, to work on that in a particular sprint. Basically create the Sprint backlog. Creating a sprint backlog is very easy, let's go ahead and choose the work that we wanna do, and we'll go ahead and drag it into our Sprint. If we click on are sprint will be able to see our Sprint backlog. The Sprint backlog behaves exactly like you would expect, you can prioritize work by dragging it and dropping it, you can add new work as well... Hmmm the other thing you can do is... you can break down your work into individual tasks that you want to do. As we said, tasks are usually about 4 hours worth of work so for this particular workitem maybe I want to "Update the DB schema" and let's add another work item as well. [PAUSE] Both the product backlog and also the Sprint backlog are great at you know adding work, prioritizing work, break work down to see what you need to do. But where these........ these backlogs start to fall short is... that they aren't very good at tracking visually what's going on, or at tracking the ongoing working [PAUSE] So to do that we have the task boards... where in a very visual manner you can track and see exactly what your team is doing.... which is pretty cool [CLICK ON BOARDS] If you wanna see at a higher level what your team is working on, you can look at the kanban board instead. And this is a fully customizable kanban board that shows the ongoing state of your progress. It is super helpful because in one place you can easily see what's going on with that particular project. I can also see when a work item get stalled in in a particular column. When I notice that, I can redirect my team to work on that particular stalled work item. There's also a really deep integration between GitHub and Azure Board, let's see it in action. [MOVE WINDOW] Let's go ahead and bring up GitHub. If I make some changes to my file, all I need to do is... in my commit message I just need to do this... Let's say we are working on work item 425 All I have to do is writing the commit message with FIXES AB #POUND 425, where AB stands for Azure Boards. When I do that, when I go ahead and Commit this change... seen that work item just magically fly over to the Done column? That's because of that deep integration between GitHub and Azure Boards. On top of that if we go ahead and look at this particular work item you will see that it linked this work item to the commit that actually happened within github. So if we go ahead and click on it, this is link that will take us to GitHub and we can see exactly what we did. Cool right?
- Alright, we’ve covered a lot today. We’ve seen what DevOps is, how to manage the work with Scrum, and the seamless integration between GitHub and Azure Boards. Thank you for joining me, and have a great rest of the conference! Back to you Aaron
- Tailwind Traders is now almost ready to start diving into coding. But they still have one process question. What branching scheme do they want to use?
- Traditional branching schemes involve many long living branches. Dev branch, QA branch, Feature branches, UAT branch, Main branch. Etc. Having all these long living branches is not conducive to moving quickly. Any time you need to merge code from one long term branch to another….
- BOOM! A merge bomb goes off. Guess what, you are going to get code conflicts. And fixing all those merge conflicts is not easy, or pleasant or quick to do! This is an extremely painful and expensive problem that EVERYONE runs into if they use long running branches. To solve this problem
- Tailwind Traders has decided to use trunk based development. Where they are basically deving and releasing off the main branch. When a dev picks up a user story, they create a topic branch, do their initial work, and very quickly merge that topic back into the main branch. With no long running branches, there are almost no merge bombs and any merge conflicts that do exist can be resolved quickly and easily. Easy peasy right? Problem solved!
- But some of you are probably thinking, HOW CAN THIS POSSIBLE WORK? If they are practically dev-ing off of the main branch, how are they not introducing bugs all over the place right???
- They solved that problem by using a software technique called Feature Flags or feature toggles or switches. Feature flags is a technique that lets you turn on or off certain portions of your code during run time.
- In one deployment, you can now ship alternative codepaths. And during run time, you can pick which path you want to go. This is awesome because now, you have separated deployment of code from the delivery of your new feature! This makes things SUPER flexible!!!!! Because of that, every new feature and every new bug fix Tailwind Traders writes must be wrapped in one of these flags. Now, they can check into master without fear. As long as the flag is off, the “new” code does get run. Only the old code.
- From a code perspective, there really isn’t any magic with feature flags. They are glorified if statements. Actually, check that. They are not glorified if statements. They are literally if statements. They really are super easy to implement. I’ve come across many companies that tell me, “oh, feature flags look awesome, but we aren’t ready to use feature flags. Our application isn’t architected in a way to support feature flags.” That’s just ludicrous. If your “architecture” supports having an if statement, guess what? Your app is ready to use feature flags.
- Once you start using feature flags, you can do all sorts of cool stuff with them. For instance, A/B testing. Where a percentage of your traffic runs variation A and another percentage runs variation B. You can now grab telemetry and figure out which one delivers more value to your users!
- You can also use feature flags to do safe deployment. Where you only turn on the flag for a small percentage of your traffic, make sure everything still looks good, open up the flag a little bit more, and then a little bit more until you are very sure everything is good, and then you can turn it on to the rest of your traffic.
- And finally, if something goes wrong with your latest deployment, rollbacks are a sinch. All you need to do is just turn your flag off and voila! Done. The new feature has been rolled back.
- Let’s see feature flags in action! Demo flags
- Finally Tailwind Traders is really concerned with quality. Moving as quickly as they will be moving, they won’t have time to do full end to end functional testing so they need to shift left and build quality into their app as they are writing it vs trying to tack on quality at the end like the way traditional software is QA’d. Another thing they want to do to improve quality is to make every checkin to the main branch go through a pull request or code review. A problem they quickly ran into is that people would ignore pull requests and they would start piling up. There are AMAZING benefits with PR’s, but if you don’t do them immediately and they start piling up, your dev work comes to a grinding stop. Another problem they had when reviewing code changes in a PR is that they really wanted to SEE the changes running in a test system. Which meant for each PR, they had to build the app, package up the app, provision the infrastructure they needed, then configure it correctly, then they needed to deploy it and THEN they could see those changes. Oh, and when they were done with the PR, they needed to clean up all that mess too!!!! Sounds crazy right? Like, being able to do this for each PR would be awesome but really trying to execute this would be a serious pain! Who has the time or energy to be able to do this correctly and quickly?????
- First, pull request were getting lost in the shuffle. People would miss pull requests, some people would ignore them. And Pull Requests would start piling up. There are AMAZING benefits with PR’s, but if you don’t do them immediately and they start piling up like this, your dev work comes to a grinding stop. Another problem they had when reviewing code changes in a PR is that they really wanted to SEE the changes running in a test system. Which meant for each PR, they had to build the app, package up the app, provision the infrastructure they needed, then configure it correctly, then they needed to deploy it and THEN they could see those changes. Oh, and when they were done with the PR, they needed to clean up all that mess too!!!! So for each pull request, And there could be multiple pull requests happening at once, they would need multiple environments spun up and torn down. Sounds crazy right? Like, being able to do this for each PR would be awesome but really trying to execute this would be a serious pain! Who has the time or energy to be able to do this correctly and quickly?????
- And that’s where GitHub Actions comes to the rescue! Actions is github’s workflow engine. Where you can automate ALL sorts of things inside of github. Just as an example, I created automation using Actions to help take care of Tailwind Traders Pull Request problems. To solve the problem of PR’s stacking up with no really knowing PR’s are waiting for them, I created a swim lane in our Kanban board called Pull Requests. And now, whenever there is a Pull request, I’ll have Actions automatically create a pull request work item, link it to the github pull request and I’ll put it on the Kanban board. This way it is READILY apparent there are PR’s waiting to be looked at and if no one picks it up quickly, as the scrum master, I can jump down the team’s throat until someone quickly does it! But wait, there’s more. Next, I’ll also have this action automatically build and package up my application. Then, since I’m using Azure app service to host my app, I’ll create a staging slot where I then deploy my application. And then, since the URL to my staging slot is dynamic and changes for each PR, I use Actions to write back to my PR with a link to my staging environment for THIS PR. This makes it super convenient for the person reviewing the PR And finally, when the PR is closed, I am a good citizen and I have my action go ahead and clean up the slot from the App Service.
- Sounds pretty nuts right? Let’s check that out!
- Sounds pretty nuts right? Let’s check that out! Azure portal, show app service with no slots Make code change, create PR, show PR work item magically show up in Kanban board, show how work item is linked to the PR Show how slot is created and dynamically named Go back to PR, show comment, click it to see application deployed Merge changes, closes PR, show app service slot deleted.
- Here’s an example of what you can do with Actions triggered from a Pull Request. You can see here that our pull request triggered a number of automatic checks – 4 GitHub Actions. The result is that a new App Service slot was created (think of it as a new version of the website), our PR changes were deployed to it, and a link was posted right in the PR conversation itself! You can see there were 3 checks that ran, and one that was skipped. If we close this pull request, that skipped check will run and tear down the slot we created. So automatically, just as a result of submitting a PR, we get a new, isolated version of the changes – easily accessible – so we can test as much as we like before approving or closing the PR. Magic!
- Cool Cool!!!!! Tailwind Traders is now in a pretty good state. They have adopted the DevOps mindset. They have picked the products that will help them enable DevOps. And they have implemented the processes they will be doing with the products they picked. The fundamentals are all in place and they are now ready for some more advanced topics. Go join us in ADO 30 where we make sure Tailwind Traders delivers both High quality code while maintaining security!
- We’ve covered a lot today, so let’s recap.
- At a high level, we covered how laying a solid foundation for a DevOps Strategy could help solve the issues that Tailwind Traders has been facing. Now that Tailwind Traders has a story for source control, collaboration, and shared tooling, they are on the right track to continue down the path of a full DevOps solution.
- We talked about what DevOps is, what source control is with a quick intro to git and github, we discussed how Microsoft Teams has enabled more effective collaboration across the Tailwind Traders organization, and we looked at how Visual Studio Code can help solve for shared tooling and even more collaboration.
- If you’d like to take a deeper look into what DevOps is with overviews, tutorials, samples, and more, head over to aka.ms/all-things-devops where you’ll find our DevOps Resource Center.
- If you’d like to explore the collection of Microsoft Learn content for the AZ-400 Designing and Implementing Microsoft DevOps Solutions certification, head over to aka.ms/getting-started-devops. If you’d like to learn more about getting certified, you can head over to aka.ms/az400-cert.
- Thank you for joining us, and have a great day!