From Development to Release
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
Lucian aSterX wrote:
methods/techniques
Crossed Fingers.
Software Kinetics (requires SL3 beta) - Moving software
-
Lucian aSterX wrote:
methods/techniques
Crossed Fingers.
Software Kinetics (requires SL3 beta) - Moving software
i mean if you have a class (for example) and after testing it roughly u decide that it's ready for including it in release, how do you move the class from development to release ? without having two versions of the same project (development and release). I was thinking about creating an attribute and for the classes that are in development to set that attribute or something... any ideas ?
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
We have a good set of procedures in place that ensures every change is tested and signed-off in the release build.
Panic, Chaos, Destruction. My work here is done.
-
We have a good set of procedures in place that ensures every change is tested and signed-off in the release build.
Panic, Chaos, Destruction. My work here is done.
by procedures u don't mean programming procedures, i suppose...
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
We don't check anything into source control until it is going into release. All backups of dev code is done without traditional source control (nightly networked backups). As a result, what you are looking for simply doesn't exist in our system. Once someone feels that code is ready for release, it gets checked into source control and tested by QA. If it passes QA it gets released. If it doesn't pass QA, it is either fixed until it does pass, or it is removed from source control.
-
We don't check anything into source control until it is going into release. All backups of dev code is done without traditional source control (nightly networked backups). As a result, what you are looking for simply doesn't exist in our system. Once someone feels that code is ready for release, it gets checked into source control and tested by QA. If it passes QA it gets released. If it doesn't pass QA, it is either fixed until it does pass, or it is removed from source control.
kinar wrote:
We don't check anything into source control until it is going into release
:wtf:
Software Zen:
delete this; -
We don't check anything into source control until it is going into release. All backups of dev code is done without traditional source control (nightly networked backups). As a result, what you are looking for simply doesn't exist in our system. Once someone feels that code is ready for release, it gets checked into source control and tested by QA. If it passes QA it gets released. If it doesn't pass QA, it is either fixed until it does pass, or it is removed from source control.
Bad practice. A developer should check-in his developed code at least once a day. This is why scm systems support branches, versions and all that stuff. This way you can go back to a previous development version of your code if needed. If things go ok, then merge your development branch with the release branch and do the integration tests. SCM's aren't release repositories.
-- Miguel A. Vilariño Software Developer
-
by procedures u don't mean programming procedures, i suppose...
No, I mean written down procedures. When you are ready to build, create a branch. Label it and lock it down. All the changes between the two branches have to be tested. Then all the functions should be regression tested - this can / should be automated as much as possible. All documentation is updated and reviewed. Software and documentation go out the door. We release quarterly, roughly two months of coding and one month for release. Current release goes out the door in ten days.
Panic, Chaos, Destruction. My work here is done.
-
Bad practice. A developer should check-in his developed code at least once a day. This is why scm systems support branches, versions and all that stuff. This way you can go back to a previous development version of your code if needed. If things go ok, then merge your development branch with the release branch and do the integration tests. SCM's aren't release repositories.
-- Miguel A. Vilariño Software Developer
I can revert to my developed code at anytime just as easy as you and can merge code as well. If my CPU dies overnight, I don't lose work. As I said, all development is saved off and backed up nightly. I guess maybe I should have worded it slightly different in that we have a different source control for released versions. We have source control for development code, it just isn't in a standard repository and each developer has thier own copy. Everywhere I've ever worked has done it this way. Personally, I can't imagine the nightmare of trying to troubleshoot code across multiple versions of software if I had every bit of development code I've ever written in my release source control. This of course doesn't even take into account all the versions that OTHER developers have written. Nothing is worse than troubleshooting someone ELSES code that isn't in a production environment since you have no idea if it even works or not. On the other hand, development is much more tightly coupled with support where I work. I spend a good portion of my time dealing directly with customers or customer support (about 50% dev/50% support issues) digging through code to figure out why people are having the issues they are experiencing and offering non-development solutions to thier problems. 75-90% of the code I write will never see production and would just clutter a source control system.
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
Use a good source control system Eg Subversion and learn about branching your code.
-
kinar wrote:
We don't check anything into source control until it is going into release
:wtf:
Software Zen:
delete this;This seemed a little weird to me as well. We have 2 sets of source control, dev/UAT and release and the developer has no access to the release version. Same with the databases, I can only get at the dev/UAT servers.
Never underestimate the power of human stupidity RAH
-
This seemed a little weird to me as well. We have 2 sets of source control, dev/UAT and release and the developer has no access to the release version. Same with the databases, I can only get at the dev/UAT servers.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
the developer has no access to the release version
Again, :wtf:. If that's the case, why bother with keeping the code under source control? A simple write-protected archive (such as a DVD) would be sufficient. Our approach is to have a development branch and one or more maintenance branches. All branches are independent, which means you occasionally have to duplicate fixes across branches. Our usual approach to fixing problems from the field is to correct them in the appropriate branch, and then promote them forward to later branches as necessary. Builds get archived to DVD and are generally sacrosanct. Builds that are sent to manufacturing are placed under document control. The only time we have returned to a given build and corrected a problem were in two cases where we copied the source for a specific build to a development machine, changed one or two lines of code, recompiled, and delivered a patch to a customer. Those were very unusual cases (and unusual customers).
Software Zen:
delete this; -
Mycroft Holmes wrote:
the developer has no access to the release version
Again, :wtf:. If that's the case, why bother with keeping the code under source control? A simple write-protected archive (such as a DVD) would be sufficient. Our approach is to have a development branch and one or more maintenance branches. All branches are independent, which means you occasionally have to duplicate fixes across branches. Our usual approach to fixing problems from the field is to correct them in the appropriate branch, and then promote them forward to later branches as necessary. Builds get archived to DVD and are generally sacrosanct. Builds that are sent to manufacturing are placed under document control. The only time we have returned to a given build and corrected a problem were in two cases where we copied the source for a specific build to a development machine, changed one or two lines of code, recompiled, and delivered a patch to a customer. Those were very unusual cases (and unusual customers).
Software Zen:
delete this;Gary Wheeler wrote:
Builds that are sent to manufacturing
This indicates you work for a software house (I work for a small, but important, department in a tier 2 bank) and you have much more stringent requirements that I do. I do NOT work on client facing transactional systems. My release cycle can be days and sometimes hours for a critical fix.
Gary Wheeler wrote:
development branch
I use Source Safe X| which may include branching but I have neither the knowledge nor the inclination to get that knowledge wether it supports branching. A corporate development environment is DRAMATICALLY different to a commercial production house. I only need to cater for a defined set of users and can smack them if they are too obstinate, makes life MUCH simpler. I also control the environmant - very important when limiting the scope of a system.
Never underestimate the power of human stupidity RAH
-
Gary Wheeler wrote:
Builds that are sent to manufacturing
This indicates you work for a software house (I work for a small, but important, department in a tier 2 bank) and you have much more stringent requirements that I do. I do NOT work on client facing transactional systems. My release cycle can be days and sometimes hours for a critical fix.
Gary Wheeler wrote:
development branch
I use Source Safe X| which may include branching but I have neither the knowledge nor the inclination to get that knowledge wether it supports branching. A corporate development environment is DRAMATICALLY different to a commercial production house. I only need to cater for a defined set of users and can smack them if they are too obstinate, makes life MUCH simpler. I also control the environmant - very important when limiting the scope of a system.
Never underestimate the power of human stupidity RAH
Actually, I work for a hardware manufacturer. The software I help write runs the equipment. You are correct though, in that we have fairly stringent documentation requirements. Some of these are based on ISO-900x concerns. A lot of them arise from the fact that this is a hardware organization, managed by former hardware engineers, and they haven't a clue how to deal with software, other than treat it like a particularly squishy form of hardware. One of my long-standing rants has been that, if Microsoft treated software releases the way we do, Bill Gates would be a clerk in a mini-mart :-D.
Mycroft Holmes wrote:
use Source Safe which may include branching but I have neither the knowledge nor the inclination to get that knowledge wether it supports branching.
We also use SourceSafe. It's builtin branching works on a file basis, and does not branch projects. This is okay, as long as you don't use file sharing excessively. We use file sharing, so I had to write a branch application that would branch projects and maintain file shares between subprojects.
Software Zen:
delete this; -
Use a good source control system Eg Subversion and learn about branching your code.
Wow, just wow. Most responders to the original poster sound like scary cowboy programmers :) Finally the correct (and only viable) answer.
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
Sourcesafe for code control, plus a home-grown change request system that stores all correspondence with customer, tests and results, etc.
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
I use subversion through TortoiseSVN[^] for version control. For every iteration or release delivered I create a branch, that represents that release, and continue developing in the trunk for new functionalities or improvements. This way I will always have a release ready anytime despite the development I've done after. I could even do little bug corrections specific to a release and republish it. For issues tracking, change requests, etc, I use JIRA[^]. It is pretty good, satisfies all my needs. Regards, Fábio
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
I have a lot to say on this subject but if you could provide more details I could answer specifically. What type of project is it? How large is the team? What hardware is available? If your asking this question I am going to assume its more than just you so you would need at a minimum: * Source Control for change tracking, Subversion is usually what I use cause its free and theres a lot of resources. * Bug Tracking software. I like the Seapine products however you can use any of the tons of free products BugTrack. Ive used GoogleDocs for this in one case. * Continuous Integration Tool. Have a dedicated machine set up for building constantly off of source checkins. Its really easy to setup and will help mitigate crappy checkins. CruiseControl or CruiseControl.NET either one can be set up in 15 minutes. * Some sort of Automated Testing tool. For web apps I use WaTiR. Ruby based testing language. Again can be setup in a couple hours. Tests will take longer to write but will save a lot of time in between. These are things at the very least that I would implement. As for the decision to enter into different stages, thats entirely up to you. If you know what your target is then its pretty simple. You get to that point, then freeze the code. Test the heck out of it and fix those bugs. If the product manager (or client) agrees all the functionality is met and Quality Assurance agrees it works properly it should be released. Depending on the type of application you may need an installer. Please provide whomever is writing the installer with a detailed outline of prerequisites. I usually develop this concurrently with the product so its ready to go when the products done. This is all at the minimum. As a project, team gets bigger I've included lots of things. Code metrics and other such reports, performance environments for load testing, hosted environment testing, bug triage sessions to determine the priority of bugs, nightly builds with automated deploys. If there are multiple projects running there are tools to distribute an parallelize these build processes. Whatever the case as long as you decide on a process and stick to it, you will increase the quality of the product. Anyone looking for more info on a specific project feel free to drop me a message costas0811 @ hotmail . com , without the spaces obviously...
-
What methods/techniques do you know for passing a software from development stage to release stage, and how do you do it ? how do you keep track of the changes, bugs, etc.. ?
A good source control (Source Safe, TFS - Team Foundation Server, Vault and etc.) and several environments (Dev, Test, Staging, Production) are required to make sure that bugs will not find their way to your release code. Basically, developers should be free to write their code on Dev. Test environment should be updated once development is ready to make any releases that are working on Dev. After testing is passed on Test environment then deployment should be done on Staging server which should have Data synchronization with prod. After finally QA approves staging version is in a good shape to go, then deployment on Production is planned and done. http://www.sesp.cse.clrc.ac.uk/Publications/TestingTools2007/swtesting/node4.html