Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the method of micro-service requirements and code management". In daily operations, I believe that many people have doubts about the methods of micro-service requirements and code management. I have consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what are the methods of micro-service requirements and code management?" Next, please follow the editor to study!

The abbreviation of business is demo, micro-service architecture. N multiple micro services. Service naming: business abbreviation-application name-type (demo-hello-service). Feature branch development, version branch release. Each requirement (task / story) corresponds to a feature branch. Each release corresponds to a version branch.

1. Requirements and code management

As a requirement and defect management, Jira adopts Scrum development method, and the project name in jira is consistent with the business acronym (demo). Gitlab as a version control system, each Group corresponds to a business, and each micro-service corresponds to a code base.

Requirements are associated with code: create a task / story in jira, and then automatically create a feature branch in that module as ISSUE (task / story) ID. The module at this time is equivalent to the project (code base) name of each microservice. Take the following figure as an example: we have created a module demo-hello-service in the demo project, which actually corresponds to the demo-hello-service service of the demo group in the Gitlab code base.

Feature branch: after you create each module, you can associate the requirements with the code. For example, in the Jira project demo, we create a question of type story (unlimited can be other), and the point is that we need to associate the changed story with the module (only with the module, we can know which code base which question is associated with through the interface).

Version branch: when the feature branch development is complete and the test verification is complete, create a version branch based on the trunk branch, and then merge all feature branches into the version branch. At this point, a release version can be created in Jira, and then the problem is associated with the release version (this action indicates that the feature branch has been verified and can be merged). Automatically complete the creation of the version branch and the merge request from the feature branch to the version branch.

two。 Configuration process

The requirements are associated with the code base, and the main tool chains used are: Jira + GitLab + Jenkins. Jira is responsible for creating requirements and configuring webhook. Jenkins is responsible for receiving Jira webhook requests and then implementing the creation of GitLab project branches through the interface.

Feature branch automation: when we create a problem on jira, the corresponding Jenkins job is triggered through Jira's webhook. The Jenkins job finds the problem name and module name by parsing the data passed by Jira webhook. Call the GitlabAPI project query API to find the code base according to the module name. Call the GitLabAPI branch creation interface to create a feature branch based on the trunk branch according to the problem name. The mission is over.

Version branch automation: Jira creates release versions and Issue associates versions. Automatically create a version branch based on master in the gitlab code base and open the merge request from the feature branch to the version branch.

2.1 preparation work

In Jenkins, create a Pipeline job and configure GenericTrigger triggers to receive JiraWebhook data. The projectKey parameter represents the name of the Jira project, and the webHookData parameter is all the data of Jira webhook. Token is the trigger token of the trigger. The job name is used by default here (the job name should be unique).

Triggers {GenericTrigger (causeString: 'Trigger By Jira Server-- > Generic Cause', genericRequestVariables: [[key:' projectKey', regexpFilter:']], genericVariables: [[defaultValue:', key: 'webHookData', regexpFilter:', value:'$]], printContributedVariables: true PrintPostContent: true, regexpFilterExpression:', regexpFilterText:', silentResponse: true, token: "${JOB_NAME}")

Configure Webhook in the Jira project, check the trigger event and enter the trigger URL. Http://jenkins.idevops.site/generic-webhook-trigger/invoke?token=demo-jira-service&projectKey=${project.key} (this address is generated by jenkins Generictrigger and will not be introduced too much here)

Jira webhook data reference, these parameters can be formatted through readJSON in Jenkinsfile, and then get the value.

Response = readJSON text: "" ${webHookData} "" println (response) / / get the event type of webhook env.eventType = response ["webhookEvent"] {"timestamp": 1603087582648, "webhookEvent": "jira:issue_created", "issue_event_type_name": "issue_created", "user": Object {...}, "issue": {"id": "10500" "self": "http://192.168.1.200:8050/rest/api/2/issue/10500"," key: "DEMO-2", "fields": {"issuetype": {"self": "http://192.168.1.200:8050/rest/api/2/issuetype/10001"," id ":" 10001 " "description": "," iconUrl ":" http://192.168.1.200:8050/images/icons/issuetypes/story.svg", "name": "story", "subtask": false} "components": [{"self": "http://192.168.1.200:8050/rest/api/2/component/10200"," id ":" 10200 "," name ":" demo-hello-service " "description": "demo-hello-service App"}], "timespent": null, "timeoriginalestimate": null, "description": null,...

2.2 encapsulate the GitLab interface

Gitlab interface document: https://docs.gitlab.com/ce/api/README.html

Shared library: src/org/devops/gitlab.groovy

Package org.devops / / encapsulates the HTTP request def HttpReq (reqType,reqUrl,reqBody) {def gitServer = "http://gitlab.idevops.site/api/v4" withCredentials ([string (credentialsId: 'gitlab-token', variable:' gitlabToken')]) {result = httpRequest customHeaders: [[maskValue: true, name: 'PRIVATE-TOKEN', value:" ${gitlabToken} "]], httpMode: reqType ContentType: "APPLICATION_JSON", consoleLogResponseBody: true, ignoreSslErrors: true, requestBody: reqBody, url: "${gitServer} / ${reqUrl}" / / quiet: true} return result} / / update file content def UpdateRepoFile (projectId,filePath FileContent) {apiUrl = "projects/$ {projectId} / repository/files/$ {filePath}" reqBody = "{" branch ":" master "," encoding ":" base64 "," content ":" ${fileContent} "," commit_message ":" update a new file "}"response = HttpReq ('PUT',apiUrl,reqBody) println (response)} / / get the file content def GetRepoFile (projectId) FilePath) {apiUrl = "projects/$ {projectId} / repository/files/$ {filePath} / raw?ref=master" response = HttpReq ('GET',apiUrl,'') return response.content} / / create warehouse file def CreateRepoFile (projectId,filePath,fileContent) {apiUrl = "projects/$ {projectId} / repository/files/$ {filePath}" reqBody = "" {"branch": "master", "encoding": "base64", "content": "${fileContent}" "commit_message": "create a new file"} "" response = HttpReq ('POST',apiUrl,reqBody) println (response)} / / change submission status def ChangeCommitStatus (projectId,commitSha,status) {commitApi = "projects/$ {projectId} / statuses/$ {commitSha}? state=$ {status}" response = HttpReq (' POST',commitApi,'') println (response) return response} / / get project ID def GetProjectID (repoName='') ProjectName) {projectApi = "projects?search=$ {projectName}" response = HttpReq ('GET',projectApi '') def result = readJSON text: "" ${response.content} "" for (repo in result) {/ / println (repo ['path_with_namespace']) if (repo [' path'] = "${projectName}") {repoId = repo ['id'] println (repoId)} return RepoId} / / Delete branch def DeleteBranch (projectId BranchName) {apiUrl = "/ projects/$ {projectId} / repository/branches/$ {branchName}" response = HttpReq ("DELETE", apiUrl,''). Content println (response)} / / create branch def CreateBranch (projectId,refBranch,newBranch) {try {branchApi = "projects/$ {projectId} / repository/branches?branch=$ {newBranch} & ref=$ {refBranch}" response = HttpReq ("POST", branchApi) ''). Content branchInfo = readJSON text: "" ${response} "} catch (e) {println (e)} / / println (branchInfo)} / / create merge request def CreateMr (projectId,sourceBranch,targetBranch,title,assigneeUser=") {try {def mrUrl =" projects/$ {projectId} / merge_requests "def reqBody ="{" source_branch ":" ${sourceBranch} " "target_branch": "${targetBranch}", "title": "${title}", "assignee_id": "${assigneeUser}"} "response = HttpReq (" POST ", mrUrl,reqBody). Content return response} catch (e) {println (e)}} / / search branch def SearchProjectBranches (projectId) SearchKey) {def branchUrl = "projects/$ {projectId} / repository/branches?search=$ {searchKey}" response = HttpReq ("GET", branchUrl) ''). Content def branchInfo = readJSON text: "" ${response} "" def branches = [:] branches [projectId] = [] if (branchInfo.size () = = 0) {return branches} else {for (branch in branchInfo) {/ / println (branch) branches [projectId] + = ["branchName": branch ["name"] "commitMes": branch ["commit"] ["message"], "commitId": branch ["commit"] ["id"], "merged": branch ["merged"] "createTime": branch ["commit"] ["created_at"]} return branches}} / / allow def AcceptMr (projectId,mergeId) {def apiUrl = "projects/$ {projectId} / merge_requests/$ {mergeId} / merge" HttpReq ('PUT',apiUrl,'')}

2.3 shared Library configuration

At this point, the study on "what is the method of micro-service requirements and code management" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.