ChatGPT Content Creation Revolution

So let us go into the lesson one. So this lesson we will be seeing on how do you do a transformation plan? What do you mean by transformation planning? What are you going to do that? So for your DevOps team, you need to actually identify what is going to be your transformation team. How are you going to Define your goals and how are you going to achieve that goals and what is the timelines for the goals and everything because if you are going to implement DevOps in your organization or in your team without knowing the goals or without knowing of what project or what team you are going to implement it and without setting a timelines. It will be very tough. So you have to set a reliable goals. You have to actually share that goals with everyone and there has to be a proper timelines in place. And then as a team effort, everyone should work together to achieve that goal. So, how do you separate transformation teams? There are several challenges while you actually create a teams. What are all the challenges of course availability of staff because you will not know like who will be interested to actually transform themselves into a new team because they have to come out of their comfort zones. For example, if you are actually creating an automation team the people who is actually working for last five six years on the same job how they will not be quite interested to go to the automation team because if it is going to be an automation team, then there has to be a lot of scripting in place. They have to do a lot of work which they are not comfortable with. So they what they will be thinking is like, okay, let me be in the same team. Why should I actually transform myself into another team? So availability of staff is very tough. The next one is like disruption of current procedures and process actually. So it should be a process. So what it is. So this is what I was mentioning about. So no one would be interested to actually disrupt their current process and procedures. So if I'm flexible in doing a thing for last one year or two year, I'll be so much happy if I'm actually doing it continuously. I don't want to try something new and then get into a problem that is called as disruption of current process and procedures. And how do you overcome these challenges and create a team? You have to focus on the transformation. You have to make them understand like if you are trying to make a formation or a transformation, then it will be it will be useful for a company. It will be useful for themselves and you have to you have to actually change their mindset and then you have to make sure like they are well respected in their subjective areas. So you have to tell them like, okay, no one would be able to do it. You are the best in net. So you have to come and make us implement these changes. So you have to actually entertain or you have to respect their subject matter expertise and make them feel comfortable towards it. And you have to make a lot of internal and external hirings as well for this particular business. So this transformation will definitely be in conflict with an ongoing business because as I was telling you about it will definitely be a conflict because your current running business, you are entirely changing it to a new process and new methodologies and everything. So it will affect your current business, but you have to make sure no one is getting impacted out of it. And how do you define a shared goals? A shared goals are nothing but it has to be shared across all the team members and everyone. So, how do you do that? The project must have a clearly defined measurable outcomes. For example, reduce the time spent on fixing the bugs by 60% so if a testing team is actually working on always finding the bugs always resolving their issues and everything then you have to make sure like they are doing it only 60% of the time. Okay, and you have to reduce a lot of unplanned work by 70%. So if any ad hoc works are coming to the place, then you have to reduce it. You have to tell them like let it be a planned work create a ticket and then we will be doing it. You should not actually accept all the unplanned work. So you have to reduce it by 70% and then reduce out-of-office or out-of-hours work required by the staff no more than 10% of the total working time, which means you can extend for one or two days, but it should not be a daily practice. Like if your office timings is 9 to 6, you can extend for one or two days up to 7 o'clock. But if it is a daily practice, then you should not actually do it and then remove all the direct patching of the production systems. So no one should actually work on the production systems directly and you should try to avoid that of direct patchings and everything to the production systems to make sure like the project is stable. So these are all just a basic examples of your shared goals. And once after the key aims of DevOps is to provide the greater customer value. So the outcomes should have a customer focus also. So that is just an ultimate value of DevOps. So what what is the need of DevOps DevOps value is to provide a customer value with a high focus on it. So for that you need to achieve certain goals and you need to work on that. That is how you will be defining a shared goals. And obviously you should set up a timelines for it because if I'm actually setting up a goal and I don't have a timeline for it, then we will not be working towards it. So you should actually set a timeline for it as well. So, how do you measure a goals with the timelines timeline should be a constant series of short-term goals each and clear measurable. Okay for the next one month. I'm going to do this and after one month I need to measure that whether I was able to do it or not. I should not have a goal of long-term for five years so that I can wait for five years and then measure it. No, your goal should be always short-term and it should be easily measurable. So what is the advantages of it? It is easier to change the plans of priorities whenever necessary. So imagine like you are having a short-term goal of two weeks or three weeks and if something something was happens also after three weeks, you can change your goals. You can change your plans and you can change your timelines. Imagine if you have a larger goal of five years when after five years it will not be easy for you to go and change it. That is why shorter goals are always preferable. And then reduce delay between doing the work and getting the feedback. So obviously at the end of the goal or at the end of your timeline, someone has to validate it. Someone has to provide the feedback and everything. So it helps you to reduce a delay as well and easier to keep the organization support when positive outcomes are apparent. So if suppose your short-term goals are successful, then it will be easy for the organization to provide your support as well. So these are all the basic things on your modules. Welcome back. So in this lesson, we will be seeing on how do you do a project selection? So as I was telling you about in our earlier lesson like this module is completely going to be a theoretical module and it does not have any labs. That's because we have done all the labs before and this module is just to tell you how do you select a DevOps project? And how do you implement your DevOps project? How do you set up a goals? How do you measure your goals and everything? So just stay focused on the theoretical part and then it would be easy for you guys to understand. So this particular lesson deals on project selections. What are all the general projects available for us? So there is a Greenfield projects and there is a Brownfield project. We will be seeing it on our upcoming slides and how do you choose between Greenfield and Brownfield and what is the system of record as a system of engagement and how do you group to minimize your initial resistance and what is project metrics and KPIs? So what is a Greenfield projects and a Brownfield projects? So this is a common terminology which will be used on your DevOps field. So as the name indicates Greenfield is nothing but it is a brand new project that is going to start from the scratch. That is a Greenfield and Brownfield projects or something which is already running for a couple of more years and you have to migrate that so that is a Brownfield on a nutshell. This is what Greenfield projects is and Brownfield projects is and how do you choose between a Greenfield and the Brownfield projects Greenfield projects as appears it is easy as a starting point because it is where the project is starting from the scratch and it is generally a blank slate that offers you to change and implement everything whatever you want because the project is not even started. So you can implement all the changes all the new process technology, whatever you want to do we can implement it whereas Brownfields actually comes with a baggage of existing code base because I told you it has been running for the last couple of years. So it has a huge code base and already an existing teams are there and often comes with a huge technical depth technical depth in the sense like there might be some lot of vulnerabilities in the code. There might be already a lot of problems in the project teams. A lot of issues may come in as a existing ones in the Brownfield projects. And one more thing is like we need to spend a huge amount of time in maintaining the Brownfield applications because it is a running applications and you cannot disturb it. So you need to spend a huge amount of time in migrating a Brownfield projects. So depending upon that you need to choose if okay, if I'm going to implement a DevOps practice or if I'm going to implement a new DevOps tools or technologies you have to choose. Okay, which one do I need to choose? So Greenfield projects are always preferable because it is easy to do whatever we want because it's a new project. But if you are going to do it on a Brownfield projects, then we need to plan accordingly with a lot of short-term goals and everything and then only we can achieve it. Okay. So what is system of record was a system of engagement. The system of record is nothing but it emphasizes accuracy and security perspective and it provides truth about all the data elements and historically evolved slowly and carefully record is nothing. But what is the record record is nothing but the place where you can have all your data all your history all your application details and accuracy of all the details. Everything is provided on a record that is going to be your system of records. Okay system of engagement in the sense like it is it is going to be your detailed explanation and it uses a lot of experimentation to solve the new problems and it is modified regularly and making changes to quickly prioritize over what are all the changes are correct. So you can call this as your what you call a standard operating procedure is so peace. So like how for example, if you are actually changing a new process, you need to come here and update it. So if I'm if I need to click on this menu button and then go to the next menu button, I need to update it over here. So that is going to be your detailed explanatory and regularly updating one. So it is generally called as standard operating procedure document kind of things where a system of record is nothing but your initial agreement one where you're going to capture all the data's and everything and it is going to be accurate and have a lot of security in place and both of these are very important for a DevOps system. And how do you select groups to minimize an initial resistance? So there are different types of staff members available. One are canaries canary people are the ones who voluntarily test the bleeding edge features. Like if they wanted to test any new features, those people are called as canaries people. If you are going to test something new or if you are going to test any new features only to the particular audience, then they are called as early adopters and third one is a users users are nothing but they just consume the products after canaries and early adopters, which is going to be a general public. Okay. So the first canary always will be an internal team or internal testing team who will be doing this testing and then comes a betas beta are the ones who is going to be your early usage people like you will be releasing it to a standard set of people that are called as early adopters and the last comes a general public which is called as a users. So whom do you think is ideal DevOps team members? Ideal DevOps team members is needed to change and have shown ability to innovate the one who is ready to get changed and one who is ready to innovate new things or ideal members for the DevOps team and they are well respected and have broad knowledge of the organization and how it operates actually ideally. They already believe in what is DevOps practice and what it is needed. So if a specific set of people are already having these capabilities and these what you call the ability to change themselves the ability to understand the Technologies the ability to innovate those are all the people who is already or those are all people who is ready to go move themselves to a DevOps team. And who are all the ideal target improvements? It can be like we can use or we can gain early wins and it is small enough to achievable in a reasonable time frame and has benefit that significant enough to be an obvious in the organization. So what do you mean by that? So what is going to be our target improvement? So you should always choose a project which is which which actually is easy for us and given early wins and it should be as small as possible so that we can achieve something on a reasonable time frame and by doing that whether it's giving me a high significant enough to be an obvious to organization. There might be certain projects in your organization, which is a small project, but it gives a high revenue for your company. So you have to choose such kind of projects which is going to be having small code base and small time frame and everything where you can easily adopt DevOps. So we need to implement that over the DevOps space and make a lot of improvements and everything that gives a value add to the organization. Thus an organization have a huge impact on us. So what do you mean by project metrics? So by doing all these things, how do you measure success? So you need to have a project metrics and KPIs KPIs are nothing but key performance indicators. So what what are those so faster outcomes? So as I was telling you about we need to identify how do you easily do a lot of changes across an organization or how do you easily do a CICD for a particular projects that is where your deployment frequency comes and deployment speed comes in deployment size comes and I leave time comes in cycle time comes in all those things are just a key performance indicators for that particular faster outcomes. And how do you measure efficiency efficiency? You can measure by server to admin ratio staff members to customer ratio application usages application performance response time server time and all those things will help you to identify the efficiency of that particular application. And how do you measure quality and security of an application? So the lesser number of downtime failures and the deployment failure rates and application failure rates mean time to recovery and bug report rates test passing rates defect escape rates availability rates SLA is nothing but service level agreement achievement and mean time to detection. So these are all just a key performance indicators for our quality and security and the final one is my culture. Employee morale and the retention rates how many people are staying in your company? How many people are actually going out due to these changes. Those are all called as cultural metrics. So the faster outcomes the efficiencies quality and security and the culture all these are called as project metrics and the deployment frequencies and then performance indicators and lead time cycle time SLS retention rates. All these are called as KPIs. Okay, so for any projects whether it's a DevOps project or it's a normal project. These are all the main project metrics and the key performance indicators that we need to capture to make sure like our DevOps team implementation is going to be successful or not. So in this lesson, we will be seeing on how do you actually form a team structure? So what are the things that we will be covering it as part of this lesson. We will be seeing on agile development practices and how it is defined and what are all the principles of agile development? What does this send me? I mean like how do you create organization structures for agile practices? And how do you mentor team members and how do you enable in team across team collaborations and how do you select tools and process for the agile practices? So what is agile development practice design? So generally there are two development practices. One is waterfall and one is agile. So what do you mean by waterfall approach waterfall approach is typically a software development lifecycle approach where you will be seeing our requirements gathering phase analytics phase design phase implementation phase and testing and maintenance phase. This is going to be your waterfall approach. So what are the disadvantages of it? So it is very hard for accuracy and calculation purposes and requirements may be changing over time. So consider for example, you are actually thinking like your project might get over in six months and at the end of a six month, we are showing some demo to the client. And what if the client is actually saying like they wanted to change the demo or they wanted to actually change some requirements. So again, you need to spend another two three months for the development and implementation purpose. So it is very hard to determine. It is very hard to identify. What is the requirements and then the requirements might change in the middle time. So it is very hard for us to understand those. So those are all called as waterfall approaches. And what do you mean by agile approach and agile approach is nothing but you are still going to do the same things. Like for example, you are going to still do the same phases of software development lifecycle, but you will be doing it on a faster faster cycles. Consider for example, the same project out of six months. You are going to actually deliver it in every month. So this every month cycle is called as your sprint cycle. Okay, so every month you are creating that sprint and you are showing some output to the client and if the client is not liking that output, you can change it immediately on the next month. So you don't need to wait for six months to get a change. So that kind of flexibility that kind of mechanism is very much available on our agile technologies. So it is mainly for our shorter term outcomes. Okay, so vertical teams have been shown to provide stronger outcomes on the agile project. So we'll be seeing what is the difference between vertical team and the horizontal team in our upcoming slides. So what are all the principles of agile development? So these are all the general principles that agile follows clusters satisfying the customer and then welcoming change requirements and then deliver working software frequently and then work together throughout the project and then build projects and all motivated individuals and then use face-to-face conversation and then measure progress through working software and then agile process promotes sustainable development and then continues attention to the technical excellence and good design and then simplicity the heart of maximizing the amount of work to be done and then use self-organizing teams and reflect on how to become more of it. So these are all the general agile principles that has been given from the agile development company and this is what I was talking about. So what is the difference between an horizontal team and the vertical team consider, for example, vertical team nothing but in an organization. You have a lot of vertical teams like banking or financial services retail health care aeronautical. So there are a lot of vertical teams across the beach teams might have developers testers and database guys and everyone. So these are all called as individual vertical team and what is the horizontal team and all the other team is nothing but a common set of people who is going to support for all the vertical team for example, DevOps and then operational guys and then AI and ML guys which is artificial intelligence and machine learning guys. So these guys will be dedicated guys who will be supporting for all the verticals or a DevOps engineer can support for backing project. He can support for financial project and he can support for health care and retail project as well. So this is a main difference between your horizontal projects and a vertical projects across. Okay, and then how do you mentor team members or other practices? So what we generally do is like many teams actually hire external agile coaches or mentors. So if you're actually following an agile development for the first time lot of team members or a lot of companies generally hire agile coaches or mentors because they need a lot of training as they need a lot of motivation and other things and these mentors or trainers coaches from external will help them to do it because agile coaches have a lot of teaching and mentoring skills and agile coaches meant to be called as trainers and consultants as well some coaches or even technical expert and some coaches actually follow or a lot of focused on the agile processes. So team members must learn as they work and their first skills from others as well. Okay, and how do you collaborate or how do you enable the in team and cross team collaborations? So you have to follow this cultural changes in cross-functional teams and collaborating tooling. So cross cultural changes in the sense like you have to actually change your workspace. You have to sit together with all the other people's and your meeting room should be made as an agile meeting rooms and you should actually go out together a lot of team outings and everything has to be there and a lot of communication and collaboration should happen as part of this cultural changes and cross-functional teams are nothing but actually working with other team members and rewarding other team members such as development team plus operations team plus QA team. They have to work together and they have to give and take between each other team and they have to actually reward the other team's help and they have to put some lot of operation. This is called as cross-functional teams and how do you collaborate over tools like that is where you have slack sky teams Hangouts. And these are all the other areas where you can set up a meeting with them and you can even talk face-to-face on the meetings and you can call them directly and then clarify all your doubts. So these are all ways for in team and cross team collaborations and how do you select tools and process for agile practices? So tools can often enhance the outcome achieved because for any process or any automation tools are the main things. That is the reason to boost often enhance the outcome achieved and physical tools such as whiteboards index card and sticky notes. So these are all called as your Kanban board so you can have your whiteboard and then a lot of sticky notes and you can create a tabular column and then you can do to do in progress and done and you can tell them like okay today. I'm going to do all these things and once it is completed, you can move it to the in progress state and then once again and then one once it is completed then move it to the completed state so that people will also be motivated like, okay, you're doing this work and a lot of other people's will also follow this and then we need to use a project management toolings for planning monitoring and visualizations. So just try to use MS projects or Excel sheets or there are Jira's agile boards and a lot of other things that you use that you generally use for project management tools and screen recording tools is generally used for recording bugs and building walkthroughs and demonstrations and everything so that we can record whatever demos that you're showing you can record whatever bugs that is being captured and then you can put it on your bug trackers or Jira's or Godzilla's and other things. What are all the measurements and what are all we need to manage while defining a quality and how do you define a feature flux and how do you plan for feature flags and what is the technical debt and how do you mean manage and measure technical debt and how do you plan performance testing effectively coding variation. So first we will see what is measurement and managing a quality. So what do you mean by quality metrics? So as I was telling you about DevOps means not only an automation DevOps means delivering value to the end-user. So consider for example, if you are preparing a software called as Excel or word ready ready. Okay, and you have created all the possible automations and you have the best team in the world and you have delivered the software to the client and when the client is actually trying to do a copy and paste and if the copy and paste is not working, do you still think have you provided a value to the customer? Not exactly because you have given a best quality of software you have given a best automation. You have given the best team out of it, but still they are not able to test their features, which is a basic copy and paste. So at the end of the day, the quality that has been given to the client is not proper. So you have failed on that. That is the reason we should always manage and measure what is a quality that we are giving it to the client. So the metrics that are directly related to the quality of the code and the build and deployment process or number of failed build percentage number of failed deployment percentage and what is a ticket volumes that you're getting in and what is a bug performances that you're getting in and what is unplanned work performance or answer the unplanned work percentage that you're getting. Okay, so the next thing that we need to define this feature flags. So as I was telling you about what exactly is a feature flags feature flags is nothing but I can release certain features to the client depending upon my need. For example, if there are five users and I need only this copy and paste feature to be working only for two users. I don't need the copy and paste to be working for other three users. So in such cases I can release these features or I can release this particularly a flag to only that two users and for the rest of the users. I can make it as off. I can switch on for only those two users. So that kind of flexibilities and that kind of options is actually called us feature flags and this feature flags actually help you to develop new code, but not actually having a functionality out of it, which means as I was telling you about you are developing a new code. You are creating a new software, but it will not be available to the public until they turn on or turn off the features. Okay, and we can actually use a be testing out of it and this feature flags helps you to determine the business logic because business generally determines for whom this feature has to be enabled and for whom this feature has to be disabled and feature flags are also called as feature toggles because there is a toggling option between on and off and what are technical depth technical depths as we have seen it in our sonar cloud lesson. Technical depth is nothing but it actually describes a number of issues that is being present in your project for quite some time and which is actually incurring a loss for your project. The list of technical excuses or technical debts or all the reasons for it might be tight deadlines and lack of technical skills and no clear product ownership or a direction or lack of coding standards and no clear definitions or last-minute requirements changes a lot of other things as well. So which actually helps us to find the technical depth. So these are these might be the reasons that is mainly possible for the technical tips and technical depth is actually one of the main reasons that the project fails to meet the deadlines. So still be about with the technical depth. There might be a huge loss for your project as well. So we need to identify the technical debts and we need to clear it immediately. And how do you manage taking the left? I was telling you about the sonar cloud option. This one our cloud has to be integrated along with your CI CD and then it spans your complete code and it tells you what are all the technical debts that is available. So you can actually drill down into each level and it gives you a analysis and it gives you a suggestions as well. So we can take use of it and then we can try to resolve all our technical debts and how do you plan for an effective code reviews code reviews are one of the main things because I'm actually a new developer and I'm writing some code and I'm trying to merge it to another code which has been already existing. Okay. So what happens if my code is having something wrong? It actually destroys my entire repository or actually destroys my entire project because if I'm writing some wrong code and if I'm actually merging it with the other existing code, which is already working properly. It destroys my entire code base. So to avoid that there has to be a lot of code reviews available and the code review is generally done by the lead who knows about the projects who knows about the programming skills and everything. So this code reviews generally helps you to improve the quality of the application because the lead who is going to review your code will be reading it properly and he knows whether your code will break the application or whether your code will be proper or not. And then this code reviews process must be very efficient and effective process and at last like we must agree that everyone is trying to actually achieve the better quality. That's the goal for everyone, but you should always be mentoring and not actually blaming it. So there is a difference between mentoring and blaming. So in DevOps always there should not be blame culture. You should help him to get the quality achieved. Okay, and small groups are always best and establish an appropriate culture cost teams. So if there has to be a give-and-take policy, so if you don't know anything you have to ask him on if he doesn't know anything he has to ask you and by these always code quality will be improved and overall cost for the delays will be reduced and performance testing has to be properly planned because if you are actually using any websites or if your application is actually being facing a customer then performance testing is mandatory because you need to check the number of load your applications are going to handle and you would have seen a flipkart and Amazon is actually conducting a lot of sales like Thanksgiving sales or Black Friday sales and everything. So we don't even know like how many people will be actually accessing that website. So there might be million people who is accessing the website at the same time. So we should always do a performance testing to analyze if my website is capable enough or not. If not, the website will break. So a load testing has to be done and the performance testing has to be done in the penetration testing has to be done. There are a lot of testing that you need to do to check the performance of your website and it should be done early and very often because if there is any problem also, you will have time to recover that and it should be part of your planning because you have to allocate certain people. You have to allocate certain budgets and you have to allocate certain timelines for this performance testing and it requires certain tools like selenium ATM and there are a lot of other tools available in the market. The focus is not only about the features. It's also mainly about the performance because if the features and everything is working fine, but copy and paste is actually taking 30 to 40 seconds means the people will not love your software. So it has to be both the performance and the quality both has to be right. And we will be seeing on how do you plan for a secure development? So what are the things that we will be seeing it as part of this lesson? So this is again going to be a theoretical lesson. So just have a glance out of it. You don't need to worry about labs or anything. So we will be seeing on what are all the secure development strategies and how do you plan to implement or have security codings and how do you plan to implement the coding basis for compliance and infrastructure for compliances. So what are all the secure development strategies that is defined? So ultimately as we were discussing about security has to be everyone's responsibility. Everyone has to take the responsibility to secure their infrastructure secure their code and secure their areas and everything. So we need to protect the information that belongs to us. We need to provide education and trainings on cybersecurity to everyone. We need to ensure our code is designed with security in mind. That is why we call it a shift left because the security aspect has to start from the development perspective itself. We need to ensure our code is compliant and tested properly. We need to include secure development practices at the early stages of our software development life cycle. So DevOps makes security testing much easier to integrate that's because when you start the security as part of your early planning stages of software development life cycle, It makes everyone's life much easier. How do you plan to implement OASP security codings? So OASP is nothing but open web application security projects or it's a top 10 hacking protocols that is being followed across the world. And how do you make sure like your project is being secured and your project is not being hacked by someone else. So a secure development actually starts from the secure coding practices and there are a lot of software available on the market to actually see what is a list of ways to protect it. So we have an input validation, output encoding, authentications and passwords, session management, access controls, cryptographic practices, error handling and logging, data protection, communication security, system configuration, database security, file management, memory management, general coding practices. These are all the areas where we can see the possible security options that we need to include as part of our practices. And how do you inspect and validate the codebase? Again, there are a list of softwares that is available. So Micro Focus, Fortify software is available, Checkmarks is available, BIMscan is available. And I was telling you about OASP, ProxyScan is also available. So these softwares are actually available as part of your Azure DevOps marketplace integration or you can call it as your plugins. So you can actually install these plugins and then you can scan your codebases to check whether your software or your codebase is vulnerable or not, or whether your codebase is secure. And depending upon the suggestions, you can still improvise your codebase accordingly. And similarly, you have a lot of tools available for your infrastructure validations as well. So PowerShell, DSE, automation, state configurations, InSpec. So these are all certain softwares which helps you to monitor your infrastructure codings like ARM templates, Terraform, Ansible, Chef, Puppet. So if you are actually using these programs for creating your infrastructure, these are the softwares that you can download it as part of your plugin configurations and then you can scan those infrastructure coding and make sure that your infrastructure is also compliant and there is no vulnerabilities in creation of your infrastructure. That is what we are going to see on our lesson one, like working with artifactory repositories and how do you migrate and integrate artifacts and how do you migrate and integrate source control. So what exactly is an artifact? An artifact is nothing but the output of your CI or continuous integration build process. Consider, for example, you are having a Java application or a Java code. So the Java code that you are going to write is going to be your source code and while doing your compilation using any of your build mechanisms like naven or ant, the source code is being compiled and then generating a compiled code and that compiled code output might be a jar file or a bar file or a EAR file and that concept is called as an artifact. So this artifact we need to store it in a particular repository called as artifactory. Why do we need to store it? That's because if something wrong happens on the deployment side, we just need to go back to the artifactory and then we can roll back to the previous version. So for example, if 1.6 version is not working on a production and if it is having some issues immediately, we can roll back to 1.5 version from the artifactory. That is the reason we are actually storing all these artifacts in the artifactory as a history and versions of for our references. So an artifact is nothing but a deployable component as I was explaining to you about and Azure pipelines can work with wide variety of artifacts sources and repositories. So list of artifactories and developments on Nexus, JFrog artifactory and you can even have your AWS S3 bucket as an artifactory or Azure block containers as an artifactory or a Dropbox or a Google Drive anywhere where it is actually trying to store its revisions or versions can be considered as an artifacts and Azure pipelines can integrate with these many artifacts available and during each release we need to specify which artifact we are going to deploy it. In the sense, which version of artifact we are going to deploy it like a 1.6 or 1.5 depending upon our choice and Azure artifacts can eliminate the need of managed file shares and host private package services. So Azure DevOps itself is having an artifactory by its own. So if you are not interested to actually go for a third-party artifactories, you can still use Azure DevOps artifacts and it is actually storing all the files and everything on itself. So Azure artifacts provides universal artifact management for Maven NPM and NuGet. So Azure artifacts by default has a support for Maven NPM and NuGet packages. So how do you migrate and integrate source control steps? So we have multiple steps for it. First you need to evaluate the tools and process that you are going to use and then you need to select a branching strategy for git. So we have seen it during our git branching strategies. Lessons like what are all the different branching strategies available one is git flow and other one is feature flow and other one is like your Microsoft flow or your fork mechanism. So whichever strategy you want you can try to use that and then you need to decide how do you want to migrate in history and then maintain your old version control system. Do you still want to maintain your old version control system or do you want to eliminate that and then remove binaries and executables from the source control. So always on the source control system, we should not store our binaries and executable files. That is why we need this artifact tree in place. It should not be stored on a source control system. We need to remove all those things and then you need to obviously train your team to understand the concepts and practices for the git and then you need to perform the actual migration of the git. So this is the concept like how do you migrate and integrate the different source control system into Azure DevOps. Thank you.