MTE Slides - for women also Copy - Copy.pptx

Hrj the bio data and then we can do it

1. Software Development Life Cycle

2. SDLC Phases

3. Waterfall Model

4. Disadvantage of Waterfall Model Working software is produced almost at the end Lot of uncertainty causes high amount of risk Not a good model for complex and long ongoing projects Not a recommended model for moderate to high risk of changing requirements kind of projects Difficult or cannot accommodate changing requirements

5. Agile Methodology AGILE An iterative project management and software development approach Helps development team to release features to their customers at fast pace A gile team produces software in small amount and incrementally instead of a big large release Constant and better collaboration with stakeholders and continuous improvement at every stage Offers flexibility, adaptability to change, and high level of customer input

6. Developer Operations DevOps comes to rescue

7. Advantages of DevOps

8. Disadvantages of DevOps

9. DevOps Pipeline DevOps pipeline is a set of tools and automated processes which enables engineering team to have close interactions while building a software Main purpose of DevOps pipeline is to enable automation and that should be continuous. For example, continuous integration, continuous delivery/deployment (CI/CD), continu ous feedback, and continuous operations DevOps pipeline consists of various phases, and it tries to get rid of manual operations as much possible in these phases It can vary project to project It may include one or more manual gates that require human intervention before it proceed to next phase

10. Lifecycle of DevOps

11. Continuous Development

12. Continuous Testing

13. Continuous Integration

14. Continuous Deployment

15. Continuous Monitoring

16. Continuous Feedback

17. Continuous Integration Acceptance Test Deploy to Staging Deploy to Production Acceptance Test Deploy to Staging Deploy to Production No Switch Test Build Source Code Test Build Source Code DevOps Pipeline Continuous Delivery Continuous Deployment Manual Switch The management of deployment pipelines can be approached prior to releasing artifacts into production. Continuous Delivery and Continuous Deployment are the strategies focusing on the roles of manual intervention and approval automation.

18. Continuous Delivery and Continuous Deployment Continuous Delivery Automates the software release process, but requires a manual decision to deploy to production. This gives developers time to review changes and coordinate with other business activities. Continuous delivery is a good choice for organizations that need to balance speed and reliability.  Continuous Deployment Automates the entire release process, including the deployment to production. This means that every change that passes all stages of the production pipeline is automatically released to customers. Continuous deployment is a good choice for organizations that want to quickly innovate and minimize release friction. However, it has a higher risk because of the lack of manual intervention

19. DevOps Lifecycle

20. DevOps Ecosystem

21. Market trends of DevOps

22. Market trends of DevOps

23. Market trends of DevOps

24. Market trends of DevOps

25. DevOps engineer’s work is a full-time job. DevOps engineers should have problem-solving and quick-learning soft skill. They are responsible for the production and maintenance of a software application’s platform. DevOps Roles, Responsibilities, Skills

26. Git Open-source distributed version control system. It is developed to co-ordinate the work among the developers. It allows to track and work together with project team members at the same workspace. It provides backups for uncertainty. Complete change history of a file. Developers can compare earlier versions of the code with an older version to fix the mistakes.

27. Git Repository Repository is the storage location where all files, packages/folders are kept. Two types of repositories – Local and Remote Remote repository is on the server and local repository is on developers local PC. Local repository is the copy of remote repository. Developers works on their local repository and push their work to remote repository.

28. Remote Repository Remote Repository Server Developer 1 Local Repository Developer 2 Local Repository Developer 3 Local Repository

29. Git config Command Git config command This command configures the user. The Git config command is the first and necessary command used on the Git command line. This command sets the author name and email address to be used with your commits. Syntax $ git config --global user.name “Rajender Singh"   $ git config --global  user.email  “ Rajender.Choudhary @gmail.com"   To view the configured details : $ git config --list

30. Git init Command Git Init command This command is used to create a local repository. Syntax $ git init demo   The init command will initialize an empty repository. See the below screenshot.                     

31. Git clone Command Git clone command This command is used to make a copy of a repository from an existing URL. If I want a local copy of my repository from GitHub, this command allows creating a local copy of that repository on your local directory from the repository URL. Syntax $ git clone URL                       

32. Git add Command Git add command This command is used to add one or more files to staging (Index) area. Syntax To add one file $ git add Filename   To add more than one file $ git add .   

33. Git status Command Git S tatus This command is used to determine the status of each file in the project. It provides which changes have been staged, which haven’t, or being tracked by Git . It also lists the files that are changed and still need to add or commit. Syntax To check the status of the files $  git  status  

34. Git Files Status Tracked files are those files which Git knows. These are referred as tracked files. The files were present in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. Remaining files are Untracked files. Any file in the working directory that were not in the last snapshot and are not in the staging area. When we first clone a repository, all of our files will be tracked and unmodified because Git just checked them out and you haven’t edited anything. As we edit files, Git sees them as modified, because we have changed them since the last commit. As we work, we selectively stage these modified files and then commit all those staged changes Untracked Unmodified Modified Staged git add Edit an existing file git add rm filename (delete a file) git commit

35. Git Commit Command Git Commit The "commit" command is used to save changes to the local repository. It is used to record the changes in the repository. It is the next command after the  git add. Every commit contains the index data and the commit message. When we add a file in Git , it will take place in the staging area. A commit command is used to fetch updates from the staging area to the repository. Staging allows us to continue in making changes to the repository, and when we want to share these changes to the version control system, committing allows us to record these changes. Commits are the snapshots of the project.  Git commit –m option The commit command will commit the changes and generate a commit-id. The -m option of commit command write the commit message on the command line. Syntax $  git  commit -m "Commit message."  

36. Git Push Command Git Push The  git push command is used to upload local repository content to a remote repository. Pushing means transfer commits from the local repository to a remote repository. After a local repository has been modified a push is executed to share the modifications with remote team members. Syntax $  git  push  If location of a repository is not specified, then it will push to default location at origin master.  

37. Git Common Commands Git Branch Command This command lists all the branches available in the repository. Syntax $  git  branch                              Git Merge Command This command is used to merge the specified branch’s history into the current branch. Syntax $  git  merge  BranchName                                        Git log Command This command is used to check the commit history. Syntax $  git  log                   

38. Git Cheat Sheet https://education.github.com/git-cheat-sheet-education.pdf https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet https://about.gitlab.com/images/press/git-cheat-sheet.pdf And many more are available on internet

39. Git Branching Model Git Flow / Git Branching Model Git flow is the set of guidelines that developers can follow when using Git. We cannot say these guidelines as rules. These are not the rules; it is a standard for an ideal project. So that a developer would easily understand the things. It is referred to as  Branching Model  by the developers and works as a central repository for a project. Developers work and push their work to different branches of the main repository.

40. Git Branches There are different types of branches in a project. According to the standard branching strategy and release management, there can be following types of branches: Master Develop Hotfixes Release branches Feature branches Every branch has its meaning and standard. Let's understand each branch and its usage. The Main Branches Two of the branching model's branches are considered as main branches of the project. These branches are as follows: master develop

41. Git Branches Master Branch The master branch is the main branch of the project that contains all the history of final changes. The master branch contains the source code of HEAD that always reflects a final version of the project. Your local repository has its master branch that always up to date with the master of a remote repository. Develop Branch It is parallel to the master branch. This branch contains the latest delivered development changes for the next release. It has the final source code for the release. It is also called as a " integration branch ." When the develop branch reaches a stable point and is ready to release, it should be merged with master and tagged with a release version. Supportive Branches The development model needs a variety of supporting branches for the parallel development, tracking of features, assist in quick fixing and release, and other problems. These branches have a limited lifetime and are removed after the uses. The different types of supportive branches, we may use are as follows: Feature branches Release branches Hotfix branches Each of these branches is made for a specific purpose and have some merge targets. These branches are significant for a technical perspective.

42. Git Branches Feature Branches Feature branches can be considered as topic branches. It is used to develop a new feature for the next version of the project. The existence of this branch is limited; it is deleted after its feature has been merged with develop branch.

43. Git Branches Release Branches The release branch is created for the support of a new version release. Senior developers will create a release branch. The release branch will contain the predetermined amount of the feature branch. The release branch should be deployed to a staging server for testing. Developers are allowed for minor bug fixing and preparing meta-data for a release on this branch. After all these tasks, it can be merged with the develop branch. When all the targeted features are created, then it can be merged with the develop branch. Some usual standard of the release branch are as follows: Generally, senior developers will create a release branch. The release branch will contain the predetermined amount of the feature branch. The release branch should be deployed to a staging server for testing. Any bugs that need to be improved must be addressed at the release branch. The release branch must have to be merged back into developing as well as the master branch. After merging, the release branch with the develop branch must be tagged with a version number.

44. Git Branches Hotfix Branches Hotfix branches are like Release branches; both are created for a new production release. The hotfix branches arise due to immediate action on the project. In case of a critical bug in a production version, a hotfix branch may branch off in your project. After fixing the bug, this branch can be merged with the master branch with a tag.

45. Jenkins Overview

46. Jenkins Benefit

47. Jenkins Continuous Integration Workflow Developer Developer Developer Code Repository Compile Build Test Deploy

48. Jenkins Installation Download Jenkins from https://www.jenkins.io/ Get Jenkins war file Open command prompt and execute java –jar Jenkins.war

49. Jenkins Launching Open chrome and type URL http://localhost:8080/ Enter the password provided in command prompt incase prompted

50. Jenkins Launching Close pop up

51. Jenkins Master and Slave Architecture In large software development program, a single Jenkins server would not be sufficient to achieve multiple job’s execution. Jenkins master slave architecture describe the optimization strategy. The Jenkins master acts to schedule the jobs and assign slaves and send builds to slaves to execute the jobs. It will also monitor the slave state (offline or online) and getting back the build result responses from slaves and the display build results on the console output. The workload of building jobs is delegated to multiple slaves. Jenkins (Master) Jenkins (Slave 1) Jenkins (Slave 2) Jenkins (Slave 3) The master node orchestrates the build process and manages the overall Jenkins environment, while one or more slave nodes (also known as agents) execute the build tasks. Master Node: Manages the Jenkins environment. Handles job scheduling and dispatching. Maintains the configuration and user interface. Slave Nodes (Agents): Execute the jobs assigned by the master. Can run on different platforms or environments. Allow for parallel execution of builds, enhancing efficiency.

52. Prepare Slave Nodes Before adding a slave node to the Jenkins master we need to prepare the node. We need to install Java on the slave node. Jenkins will install a client program on the slave node. To run the client program we need to install the same Java version we used to install on Jenkins master.

53. Trigger Jobs Periodically Select a Job and click on configure. Jenkins use cron expression which has below format: Minutes in one hour 0-59 Hours in a day 0-23 Day in a month 1-31 Month in a year 1-12 Day of the week 0-7 where 0 and 7 are Sunday

54. Pipeline as a Code A reusable method provisioning infrastructure driving automation in software delivery. Pipeline as Code allows to define the build and deployment processes as code, making it easier to version control and manage. Instead of using the traditional Jenkins GUI to create jobs, one can write pipeline logic in a text file. Pipeline as code is a way by which one can define software delivery pipelines as code, stored and versioned in a source repository. P rojects must contain a file named Jenkinsfile in the repository root, which contains a "Pipeline script.“ Presence of the Jenkinsfile in the root of a repository makes it eligible for Jenkins to automatically manage and execute jobs based on repository branches. JenkinsFile contains the steps needed for running a Jenkins pipeline

55. Jenkins File The first block is pipeline. It is the main block that contains the entire declaration of a pipeline. Pipeline block will have stages, stage and steps block. declarative pipeline structure : pipeline { agent any stages { stage('Hello') { steps { echo 'Hello World' } } } } pipeline – contains the whole pipeline agent – defines the machine that will handle this pipeline stages – declares the stages of the pipeline steps – small operations inside a particular stage

56. Simple Scripted Pipeline Click New item. Enter a name and select Pipeline. Write a simple script. Build Now