Agile and code release [closed]_问答_开发者_运维开发者技术经验分享

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

Do you know of any agile process that is created for code releases? One of the main theme of agile is frequent releases and each company/client would have their own test/approval processes that control code releases. Most of the time these slow down the pace of "frequent releases"

Currently we have a proprietary tool based workflow. The team who needs a code promotion needs to create a promotion request to开发者_运维技巧 one of the final UAT servers. Once this is complete, and once tests are done, certain customers, technical/non-technical managers need to approve, then it goes in to production deploy stage. Meanwhile no sprint planning meeting or anything of that sort.

What is the code release process (Which is agile) that has worked for you?

Why is there no sprint planning meeting of any sort while the workflow proceeds? Tag your repository and get on with the next release straight away. If you need bug fixes on the candidate release, branch from the tag and fix them. The approvals workflow and final UAT testing should not either involve or delay the development team. (Excuse non-distributed SCM terminology if you are actually on something like Git or Mercurial.)

If you take an Agile process like Scrum, the release output is "releasable software" not "released software". If you have an overhead getting stuff released to production, then it can just happen in parallel. I should add that the majority of the testing should have been as part of the sprint - perhaps you need to revisit exactly what testing is done when in your cycle?

If you are having problems testing "big" releases then your release cycle is to long. The underlying principle of release often is that often == smaller releases. If you are having problems and you are only releasing small sets of features that don't take long to test then it is your release engineering team that is the bottleneck, their waterfall approval process needs to change.

Release into a common dev environment all during the sprint, release to a QA environment during the sprint.

Release into a reference environment at the end of the sprint for the demo of only the completed ( and tested ) features.

Release to production whenever the product owners want.

Risk of bugs should not be an issue, since bugs should not have any correlation to the frequency of the releases, actually more releases should actually mean less risk and less bugs. Testing should be done during the sprint, not after. If something isn't fully tested and might be buggy then it isn't done and should not be demoed, much less released to production.

In the end release to production should be the product owners call. A politicized waterfall release engineering process almost never keeps bugs out of production, it just makes the show up later rather than sooner. Managers ticking a check box on a form with their "ok" isn't keeping buggy code out of the customers eyes. Frequent releases to QA during development will. Testing should not be part of the release engineering cycle, it should be part of the development cycle.

This depends on how mission-critical your product is. By "release", do you mean launching your life-critical software to a hospital? Or is it a casual gaming website?

If your work is mission-critical or life-critical, agile may not be able to work for you. In that case, you may need to do more formal testing before deploying.

If you work on a website that isn't mission-critical (and this is often better than not!), you have the freedom to be a little buggy. This helps you iterate faster and re-release again and again.

For that kind of product, which agile is perfect for, let developers test themselves, let clients see the results, then launch to a small group of users (hopefully randomly selected active users -- hallway testing) as soon as possible -- if it's a small thing, even to your whole userbase. On a web service, you can do this quickly and fix it without going through much pain.