Introduction:
Because our development cycle is iterated to Sprint as a unit, and each of us how to Sprint customers that our results do, then I need to Demo and release a number of new features, or some bug fixing. Demo I do not discuss here, for all to see next meeting and then run on all servers in general it is to deploy, and we are here to discuss major release (release) about the topic.
Method to realize:
Topic 1: How do we let publishers know what we do Sprint this function? Jdk because, like, like, every time it's a big release and a small release has some commentary to explain what they publish this function, or what amendments we do, our approach is:
Sprint at the end of each day, and if there is any change (functional changes / amendments) to the project, will add a release note in the project.
Specific approach is: We use the maven-site-plugin, then every time we will update the site folder, add an entry in the site.xml to "Release Notes" in:
Then we add a file apt, and where plus release notes
Now we use mvn site, you can display these release notes we write up.
Topic 2: Choose a reasonable release plan
When are we going to release artifact, this is a very difficult problem. Maybe some people want simple, is not this the next version upgrade, and then build it does not get away with it? You do far worse. Because you want to publish a project, not a simple operation, you have to have very strict quality checks for this project, which means you want to make sure its correctness, so we have to put on some products do Regression environment, If Regression is no problem, we have to go on a higher level of environment do Regression, until several environmental Regression no problem, we can safely go Release. specifically, we have four sets of environment, namely Dev, DevInt, QA, Production, we have to go up a layer, no problem, we can publish the final release and both Production environment. So the question is, since the Release to move code repository, and our development is the iteration time and is kept, if the Release team released when the project developer has submitted the code to the same warehouse, it will lead to inconsistent code leads to release failure. We now there is no strict code freeze system, because this system is mostly in the waterfall model, we can not stop development, then how to choose the right point Release time? Release Plan This is the problem to be solved.
This problem is very complex, I was invited to design the Release Plan, I thought over 2 days to come up with a reasonable solution, here to share without reservation, the concrete structure is as follows:
This figure, the yellow status bar represents the development team, the green status bar represents the test team in each Sprint, the talent has become me 10 N + 1 to N + 10, where N represents the N-th Sprint, blue text action on behalf of the development team, purple text action on behalf of test team, red text represents the release of human action.
So difficult to find from the figure for the development team, their main development date from the (N + 3) to (N + 9), a total of seven days, seven days they do develop, it will touch the code repository, and for the first two days (N + 1), (N + 2) and the last day of the (N + 10), they are all independent code and do some things, so it will not affect the go code repository. So my advice is to let people do release release and Regression in Dev and DevInt time control (N + 1) and (N + 2), because the stability of this two-day code repository can be guaranteed, then when developers submit code from the beginning 3 N +, releaser do release and regression QA and Production environments, this will not affect the development team commit code.
Risks and experience sharing:
In fact, the biggest risk for the development team, or in case UX Spec API is not very clear, or unstable, so that their development time will be delayed, may not necessarily from the (N + 3) started, for these cases, my advice is, if the (N + 1) day encounter these various negative factors of development, so as far as possible all resolved before the (N + 3), if we can solve, then the best, if not resolved, then the scrum master can cut off some of the story, so you can at least ensure that the development team delivered on time.
Also, in case of release failure is how to deal with? My advice is: If you release or regression fails, then the code will be returned to the hands of the development team, and then become a urgent fix activity. When the team is enough to force, they can be solved in N + 1, then everything is all right, if only solution to N + 2, the development team will develop a day later, from N + 4 to N + 9, which requires them to appropriate improve efficiency, cost estimation, when in fact we have also added a lot of buffer time. If not to solve the N + 3, then stop release releaser, and proclaimed N-1 iteration release fails, then wait two weeks to conduct a new round of release. The only way to ensure the smooth flow of the whole.
to sum up:
Release is a very important step, we have to put this off well.
(1) Release of the process we can use plug-ins and add a good release in sufficient detail to facilitate future notes to track the evolution of the project.
(2) design a very effective release plan is very important, crucial foothold is either a cross between a variety of roles, not each other block, there is no plan of the project will release a mess.
This article comes from " parallel lines cohesion " blog, http://supercharles888.blog.51cto.com/609344/1262090
Reproduced in: https: //www.cnblogs.com/JoannaQ/p/3251393.html