Improving DevOps Workflows | DevOps Experience 2024

Hi everyone. My name is J Wood, and today I'm gonna talk a little bit about improving DevOps workflows using generative AI and GitHub copilot. And a little bit about me.

I am the AI impact lead at GFT Technologies. I am the 18 years Microsoft MVP, the first Brazilian GitHub star. I'm four years in this program, but it's a personal honor to me to be, uh, the first one in Brazil to be part of this team.

And I'm speaking in technical conference like that. I'm YouTube about technical contents like DevOps, career, uh, productivity, and other contents like that. Here is my YouTube channel, my linkage profile, and my mail, um, if necessary.

Okay. And we are gonna talk about NAA on DevOps workflows. And I think the best important point is talking up shortly, uh, about what is, uh, generative AI because well, it surround everything about steam and about software development, life cycle, uh, in next years.

And basically, uh, TV AI is a kind of AI that, um, using algorithms to create, uh, a, a new contents like a text, like, uh, images, like, uh, videos. And in our case, create a source code, create documentations, and, uh, support us in a lot of tasks, uh, in the software development life cycle. And this tool is general call.

It is called generative AI because, well, it's a little bit, obviously because this generate a new content based on training data on historical data. And this AI can be understanding your request to generate a new content base, uh, in, uh, what you are needed here and, and to, to work with the gene. A tools, uh, important technique.

Technique was born the prompt engineering technique or the prompt engineering. Uh, it's a new for position in, in some projects right now. And what is, is this in general?

Uh, the prompt engineering is the art of crafting effective instructions to get the best response from AI models. And why I'm talking about the art 'cause it's not properly exact science because, um, we cannot have, for example, the same answer, for the same question. And, uh, we have no specific rule to create a a, a good prompting.

For example, if I request this specific question, I will be received this specific answer. It's not, um, a really true information. In general.

We need to to work as a artist to understanding what works, what not, and create a best prompt, a best approach, a fairly turnage prompt to support your creation. And it's not only for creative images or videos to create text is to create SARS codes, documentations, all of them follow the, the same instructions and the prompting properly. Basically, it's a, uh, a piece of information, a collection of information that you can provide to generative to, to generate a content base on your request.

And, uh, on, uh, and in your AI training data, the generative ai, use the both of them to generate a best answer for you. And you need to understand here, we you need to create a detailed prompt or with a more contest as possible to create a best answer. Basically, if a good things, uh, in, in the prompt, good things will be answered.

If you provide no good information in the prompt, probably your answer will not be good too. Okay. And here, for example, I have two requests that I did on GitHub copilot with basically the semi prompt in, in a, uh, it's essentially the same prompt, basically, uh, is that I'm building an application to display electric vehicle data, gimme some options for how to instruct structure GI app.

In the first one, I have no many details. Uh, I'm directly on on that I need and okay, GitHub co polish answer to me, and it's, this answer is okay, it's good answer, but it's not specific for what I really need. In the second one, I provided more information.

For example, I specified that using express and type script, or I'm large scale application, uh, I need to use a key lock tot cage. My front change will be use type script and will be deployed on Azure Kubernetes. Using all of this information in the prompt GitHub copilot can be provided to me.

Um, a more specific answer, a more useful answer to me. Uh, I not pasted here all print, but, uh, here you can see the difference about the answer. In the first one I receive, I received the options In the second I received the read the structure following my request.

Uh, in the other parts of this answer, I received the piece of codes for, uh, dock container for script stock Bernet services, uh, to scripts for GitHub actions. I received more, uh, specific information for my request, basically, as I mentioned, good things in, good things out, okay. And, uh, how this prompt works on GitHub copilot, but not only on copilot, but in general, the other tools that use in generative AI works, uh, uh, the same model.

Okay? Basically, you, uh, as user will be request something, for example, in case create a observer in TypeScript. And this information will be sent for, for GitHub co-pilot.

What happened here in, in the backend, the GitHub will be includes assistant tag here. And the system tag basically is, um, the chat bot or the assistant, uh, rule settings. And for example, this, the GitHub are including you are a friendly code assistant and probably, uh, probably the content, the most content.

Here's, uh, something like that. You'll be answer only question about source code. You are not creating vulnerabilities on the code or you are not able to answer question about politics.

Uh, all of them on system information will be create a set of rules that this, uh, this tool need to follow. Okay? And the user will be, uh, attached to your request and it'll be sent for LLM model in this case for GPT-4, GPT-4 oh or other model.

But you can use AWS models or other LLM models. It's not, don't care. And your answer will be processed by, uh, OpenAI or LLM and include here a new tag for assistant tag with the answer.

And this answer will be considered the training data, the assistant tag, the user requests to create a, a, a goods assistant message, okay? And copilot are the other, uh, gene eight tool returns for you, uh, piece of code or the answer that you request. Okay?

Okay. But probably thinking, uh, why you need to use, uh, gene eight tools on, on the ops workflows on DevOps process. And important thing to remember here is it, it's, uh, a point that some people forgot.

Forget, because, uh, the DevOps is not only about CI and CD automations, it's not about, uh, building deployed application on cloud environments or in, in other place. The DevOps is general about think entire software development lifecycle. Uh, it's about all people on this process, uh, since the ideation, the code creation, uh, the testing, q ratings, infrastructure things, monitoring process, all of them, uh, are, is a part of the software development type life cycle and the DevOps process.

And, okay, to me it's important for now in, in this specific talk for core items, focusing specifically on the developers, uh, to increase, uh, to use genera generat tools in other DevOps, uh, workflows. These key tools are enhance developer experience, increase the productivity, increase the learning and focus, uh, on the business. And why this for us, most important in my opinion, well, when I started to work, uh, in a software development a lot of years ago, I don't remember the correct year, uh, one of the first lessons that I learned from my first boss was the user experience.

Some most important part of, of the software development. Because if the user don't like your application, the application will be not, you use it. And his job, uh, is, it's a trash, basically.

It's that. And he has, it's properly, it's really true. Uh, it's important, but we forget an important part of this process.

Okay? Now more people are talking a little bit more about that, is that the developer experience? But it's not com very common yet.

And it's an important part of the software development because if the dev have a good experience in your environment, in your software creation process, the software, the the find off the job will be good too. If the developer have a good tools, uh, a good environment, a good support, uh, this job will be better. And the DAA tool can be supporting this can be improving this process.

Uh, the NAA is not focused to solve our points is not, uh, a bullet point, sorry, is not a bullet point to, to solve all problems, but it's an important thing to improve the soft, the developer experience, uh, in, in day by day. And in the same time, it can be in incre increase the developer's productivity because using gene eight tools like hack hub, copilot, for example, uh, it's not necessary more for this developer, uh, make, uh, extensive researches on the internet about, uh, common tasks because these tools are read generate suggestions, folks on, on this task. If I need, for example, to create a switch case in Java and I I not remember, uh, how can I do that?

I don't need to go to the forums, I don't need to go to the Google because these assistant I read suggest to me I need, you need to start to start to create comments and they will be received, uh, suggestions for this or using a GitHub copilot chat or other AI tool, like a chat, uh, chat experience to have, uh, an answer about that. It's increased the productivity a lot. And it is not only this, but using to automate documentation to support, uh, me to generate energy tasks is and other parts of this process and can increase my learning.

How using the same gene a tools to supporting me to understanding other parts of this project or to understand what project does. Ima imagine that you are starting in a new project and you have no information about that you can use generate tools to generate documentations, to generate explanations, to generate, um, conversational documentations to support you to understanding easier what the application does and how can you, uh, support this development team faster. Okay?

And using all of this, we can focus on the really important fire in the software development in the business because we don't need to focus anymore in the common tasks or in documenting or create a simple pieces of code. We can focus on the more important part. We can focus in the really, uh, complex part of this process to understand the business rules, what you need to implement here into the detail to, to improve the application, to create a best applications.

Okay. And in general, how can this generate tools, improve the software development, uh, to DevOps workflows? We can create, uh, talk a lot about a lot of points, but I have here five main points that we can use because this points is the, is the topics that I, I can, I'm seeing in the clients I'm seeing in my job recently, okay?

And can be increased our productivity, uh, a lot. The first one is the code creation. It's the most common using tools like a GitHub copilot because the GitHub copilot, as I mentioned before, providing you code, suggestion code, snippets, uh, documentations, code explanations, uh, support you in the code corrections support you in a lot of tasks in the, in the code creation process.

Okay? The next one is the code review. While I'm talking about code review, because, uh, well in general, it's, uh, very common or, uh, I, I I guess it's essentially 'cause all developers need to create a merger requests or a pool requests before merge the source code.

And in general, in, in theory, uh, the developers need to describe their change to support the approval chain to understanding if change, make it sense or have, uh, problems. And in general, the developers only describe merge domain or merging feature, blah, blah, blah. Uh, and it's not a new usable information.

And the approval need to go to the source codes line by line. What code does, if it makes sense or not. It's a boring process, it's a boring job to do.

And using generat tva, we can use these tools to understand the change and provide a user for, uh, description for this board request description, file by file recommendations, uh, vulnerability explanations. And I need to go only to the source codes. If I seen, uh, something wrong in the codes description or I need to call the developer to understand this change, only if I, uh, I seen something wrong in the codes description.

It's a, a good point to pro productive gain. The next one is the documentation. The idea here is documenting your source code, because we know that we have in general two scenarios, one or the second.

The first one is I don't have documentation because no one do this in the past. And the second one is, yes, I have documentation, but it's a very, very outdated documentation because someone create this in the first year of the project and no one updated this anymore. And it's a problem because in both cases I have no documentation.

And we can use generative VA tools to create in this. And you can automate in this process, uh, in a different parts of your software development life cycle. You can use, uh, the IDE from developers to create this documentation.

You can include it, this documentation process in a per request, for example, you can have a scheduled pro, uh, process to create this documentation. And in the future, we can put this in a conversational chatbot to, to, to do more easier to interact with with your documentation pro process and maintain is alive easier. The next one is the test generation.

And here we can po it is possible to create unit tests, uh, using generat, tva following company standards, following, uh, company frameworks and a lot of other important rules. And we can create here to, uh, functional testing, uh, and uh, a testing of interface using natural language. Uh, we don't need to create anymore, uh, HEML mappings, uh, CSS mapping fields, we can use natural languages to, uh, create in this testing process and all of them using general TVA a, uh, turn this job more easier.

The next one is the code correction, because we know today we have a lot of vulnerability in the code and we already use SaaS tools to, to generate a report for us about this. And so our fortify other SaaS tools, other secur tools provide those information. And you can, we can use generative VA to use this information to generate a correction for our codes and correct vulnerabilities, issues, codes, now bugs and and much more.

And in next we can do much more than that. These five points, uh, are the most common that I'm seeing here are most used that I'm seeing here today. But we can do this for example, uh, a creation of your backlog using generative a using, uh, describing the use case for a GENEA tool to create your app.

Because your features, your user stories and tasks, for example, uh, you can use this to do a reverse engineering into source code to support a legacy modernization. You can use this in not a lot of different parts of your software development life cycle to increase your productivity. Okay?

And day by day, uh, uh, a new tools are born to support us in in these parts. Okay? Uh, what tools I'm using at this moment, the first one is the most common GitHub copilot.

'cause this tool is a very interesting, it's amazing tool that support developers in, uh, DA lot of different tasks. The most common is using on my IDE to generate code suggestions to me, to generating to me, uh, code corrections to generate to me how can I create testings and other important implementations in general using these two, uh, to improve my implementations, for example. And the next one is GFDI.

Impact is that to, uh, interesting tool Fox to supporting tyro software development lifecycle using genea and this Fox to productive again. And we have here features like backlog, creation, star creation, documentation, projects, um, test creation code, reviewing code, core action code, fixing testing, uh, legacy modernization. We have a different set of tools to use in G to improve, uh, the productivity.

Okay? And I like to to to run a ADE for you ADE two demos that I have here using TGA tools to understanding how can you, you using this in, in your days? Okay, the first one, it's a more simple I'm using directly on my id.

Basically I'm start imagine that you are starting a new project, that you have no information and you need to solve your vulnerability report by a SaaS tools, document the codes and create I tests. Basically, I received this information, a SONER print screen informing me that I have SQL injection in my class user Java. What I need to do here, well, opening my ID here, I have this project, it's a, a wide open project in, in the class I can use here my GitHub copilot, for example, asking this, explain me the coach and show me a bullet list with our bilities to support me to understand if I have more vulnerabilities than, uh, I they reported.

And here I read has received a lot of, uh, information. You can see here, explanation of this code, what code does the fields that I have, constructor methods, and here the vulnerabilities, the SQI injection sensitive data expo exposure, improper exception. Basically a lot of, uh, vulnerabilities here.

What they can do here, I can request for GI type co, correct only the SQ injection are correct, the others and every request here, core O vulnerability on the codes. And here the GitHub code PAL will be understanding this and create me a new version of the source code with, uh, the vulnerabilities core actions here. And a short summary of this change.

I can copy this page, this here. And I have here a new version of this source code. And okay, now I need to do a next task documenting this code.

I can open here text letter, right click on the user and create a documentation. Basically here I need to create a problem that I'm using the language of this application and tell them that I plan to use, and I'm using the GFTI impact here to generate a documentation in the company standards. And we need to personalize this based, uh, on, on what the company needs to, to explain the code.

And here basically, uh, is the generated the documentation. We can open this in a markdown preview. And here we can see overview, process flow insights and data manipulation to generate tests basically is the same.

You can create here. Uh, you need tests. Select a prompt for eworks the language, LLM, and we can, uh, include this on existing files if necessary.

For example, if I'm creating a test is for existing project and spiritual red, have a unit test, we can, uh, add more testing for this or improving the test or correcting the test. Or if I don't have tests yet, I can create a new unit test for this project. Okay?

And here basically I have this new, uh, test class and I can commit this file and follow my DevOps process. Okay? And for the next demo, the process will be the same, but I will be create this directly on my GitHub, following my, uh, DevOps pipeline.

I'll be update the code using GitHub code pilot on web, create a pool request document, create a test and review this p pool request. Basically I'll be used, uh, i in the same repository. It's the same vulnerable project to repository.

I'll be click, click here on the copilot section and I'll be describe a task and I be request solve SQL injection on user, do Java and I'll be start this task. Basically the GitHub copilot will be understanding my source code, my vulnerabilities, and we, we propose a solution to correct this code and I can here generate a plan. GitHub copilot will be understanding the class and the steps and click, I can click here to implement this files properly and copilot regenerate a correction for us.

It's, uh, a very quick process and here we can see the old version. The new version includes correction, the SQL injection, the parallel corrections, and they be create a new pull request here to implement this change and created. And I will be open my GitHub again.

And here I have now a poor request. What happens here in the beginning, uh, that time created its poor request. A pipeline will be triggered by GitHub actions and this pipeline will be trigger my GFTI impact to create to me a documentation to create to me a unit test and then create to me a reviewing process.

It's not a long process, but we can, uh, see here the pipeline running, uh, to monitoring this, it's creating the testing for us for now. After that, we'll be saving on the pull request. And after that, the document, uh, we'll be documenting this project.

And the interest in here is that we can guarantee that all the time that the developers create a new change, create a new request, we can maintain the documentation alive and we can guarantee test that the unit test will be, uh, create automatically in your repository. For example, here, the test is already created. And here I have a new comment for the unit tests and I need to wait for the documentation PRO process.

It's a wiki process too. And, and, and all of them, as I mentioned, documentation testing. We can adapting this and create in a more specific scenario to generate for specific situations.

We can create a specific documentation for COBO projects or Fornet projects or for Java projects and following different standards for each one here, I think that the documentation now read generated two only waiting here, okay, I have the tests and documents generated. And if I'm going here for the file changes, now I have first one, the user Java, the file changes by uh, GitHub copilot. And here I have the user test Java.

I already have tests on my project for this class and GFGA impact. She understood this and only updated these tests, creating more tests if necessary, correcting tests or moving tests that was not necessary anymore. And in intent created here a documentation.

I didn't have documentation before. And for now it creates a new version. But in the next request, it'll be create only, uh, an applicated version of this documentation.

It's in markdown file and you can save in your repository or integrate in another tool that you are prefer to use. And let me go back here. And now in the per request we have the code reviewer.

And it's interesting point because it's provide for us information about the developer chains. It provide to me a description. It provides to me a summary explaining file by file, what pull request does in not only for the pull requests, uh, for the file chain by GitHub copilot or the developer, but the the for the files created by uh, GFGI impacted tools.

And here we have document, uh, recommendations for this poor request and vulnerabilities explanation. And I can see here now for example, that I have other vulnerabilities that I need to solve and I can make a decision with, I will be approved this or request to developer correct this solve other poor request is okay? Okay.

I think that's my time is now, uh, is finished it and here is my contacts. You can see here my linkage in profile, my U YouTube link again and my mail address if you like to talk with me. And I think it's now for today.

Thank you for watching my talk. My talk today.