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

Introduction:

Because our development cycle is iterative, in terms of Sprint, how do we tell our customers about our results in each Sprint, then I need some new features of Demo and release, or some bug fixing. I'm not going to talk about Demo here, but basically deploy it on the server and run it for everyone in meeting to take a look at it. Here we mainly discuss topics related to release.

Implementation method:

Topic 1: how do we let publishers know what our Sprint does? Because like jdk, each of its big release and small release has some comments on what features or fixes they have in this release, like us, what we do is:

On the end date of each Sprint, if there are any changes (functional changes / fixes) to the project, a release note.

Here's what we do: we adopt maven-site-plugin, and then every time we update site folder, we add an entry to "Release Notes" in site.xml:

Then we add an apt file and add release notes to it

Now that we use mvn site, we can display the release notes we wrote.

Topic 2: choose a reasonable release plan

It is a very difficult question when we go to release artifact. Maybe some people want to make it simple, isn't it just to upgrade the version number, and then build is done? You're not even close. Because you want to release a project, it is not so simple to operate, you must have a very strict check on the quality of this project, that is to say, you must ensure its correctness, so we must first Regression the product in certain environments. If Regression is not a problem, we also have to do Regression in a higher-level environment. Until several environments have no problems with Regression, we can rest assured that we can boldly go to Release. Specifically, we have 4 sets of environments, namely Dev, DevInt,QA, and Production. We have to go up layer by layer, and there is no problem before we can finally Release and release in the Production environment. Then the problem arises, because Release wants to move the code repository, and our development is iterative and non-stop, if the developer submits the code to the same repository when the Release team publishes the project, it will lead to code inconsistency and release failure. We also do not have a strict code freeze system, because this system is mostly in the waterfall model, our development can not be stopped, so how to choose the right time for Release? This is the problem Release Plan is trying to solve.

This problem is very complicated. When I was invited to design Release Plan, I thought about it for 2 days before I came up with a reasonable plan. Here we share it without reservation. The specific structure is as follows:

In this picture, the × × status bar represents the development team, and the green status bar represents the test team. In each Sprint, I divided 10 days into Number1 to Number10, where N represents the N Sprint, the blue text represents the action of the development team, the purple text represents the action of the test team, and the red text represents the action of the release.

So it is not difficult to see from the above figure that for the development team, their main development date is from (Nim3) to (Niss9), a total of 7 days, these seven days they do development, so they will touch the code repository, while for the first 2 days (Null 1), (Null 2) and the last day (Null 10), they all do something that has nothing to do with the code, so they will not affect the code repository. So my suggestion is to limit the time for release people to do release and Regression on Dev and DevInt at (nasty 1) and (nasty 2), because the stability of the code repository can be guaranteed in these two days, and then when the developer commits the code from nasty 3, releaser does the release and regression of the QA and Production environment, which will not affect the development team to submit the code.

Risk and experience sharing:

In fact, the biggest risk is for the development team, in case the API or UX Spec is not very clear or unstable, then their development time will be delayed, perhaps not necessarily starting with (Nation3). For these cases, my advice is that if you encounter these various development disadvantages on the Niss1 day, try to solve them all before Niss3, if it can be solved, then it is best, if not solved. Then scrum master can cut down some of the story so that at least the development team can deliver on time.

Also, what should I do if the release fails? My advice is: if release or regression fails, the code will be returned to the development team and become a urgent fix activity. If the development team is strong enough that they can solve it in Ninten1, then everything will be fine. If it is not solved until Ninten2, then the development team will have to postpone development by one day, from Ninten4 to Ninten9, which requires them to improve their efficiency appropriately. In fact, we have added a lot of buffer time in our workload estimates. If it is not solved by Numbai 3, then releaser stops the release and declares the release of Nmuri 1 iteration failed, and then wait 2 weeks for a new round of release. Only in this way can the whole process be ensured smoothly.

Summary:

Release is a very important step, and we must make good use of it.

(1) in the Release process, we can use the release plug-in and add enough detailed notes to track the evolution of the project later.

(2) it is very important to design a very effective release plan, the key foothold is that the various roles do not intersect, do not block each other, release without plan will make a mess of the project.

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.