From Development to Release
-
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
-
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
Source code in scm should (ideally) always build (and pass any automated tests). If your scm support checkout (SCCM, RCS, PVCS, Clearcase, SourceSafe*, CVS*, SVN*), you can use that to indicate to other developers modules that are in the process of being changed. (* some version don't really let you file lock) However, in times of heavy development, my co-workers and I used scm to communicate changes to the system: we checked in all of our changes and repulled at least once a day. (Sometimes far more often) We fixed anything that wouldn't build immediately. When it was ready for Testing, tag the files to indicate what went (PVCS, Clearcase, SourceSafe, SVN). Repeat tagging each time you migrate into a new environment; including Production base load and patches. Definitely look into CruiseControl / Homegrown solutions to develop an automated build system : preferrably on it's own build box.
-
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.
That's not using source control the way it should be used. You must have very small projects with very little complexity to them. - You should check in the code when you're not using it. - You should label the whole project when it's ready to be tested and notify QA to do so. That way others can modify the code and you have a history of changes, sort of like an extended undo on larger projects. You could also work on the code from your own copy stored on your hard drive making compliles 100X faster. Nightly back ups? So what if your hard drive or server caught fire just before the backup?
-
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're always in "release" stage and the code is put in the deposit from day... say first hour... Occasionally we end up with projects that we need to delete as the project was cancelled (if put on hold, they will stay in the repository ad infinitum until another decision is reached). Every project environment (ide, data, document, components etc) are burned to a DVD upon the first release unless it's a trivial setup then it will just be a comment on which IDE to use, global settings included in the repository). If a issue is serious, there can be a release as the fix is confirmed and accepted. It's not that uncommon (neither common) to have five-six releases a day, sometimes different products, sometimes not (once there was _no_ release of anything for three full months)... Our releases progress up from; Development (not leaving the developers machine but they could be working on a customers behalf) Internal usage inside the company. Advanced "almost internal" users. Advanced customers that use the program in ways we never envisioned but they do also accepts that we occasionally get things wrong. Customers with a special standing with the company End users -- COTS Now this is quite a special setup but I think it can be explained as development+testing/testing/QA/public beta/release candidates/release. rgds /Jonas ps. We have somewhere between 10-15 projects running in parallel (out of 38)....
-
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 what we call a process running via teamsystem - will get back to the inner workings of our build process. Basically, the customer/BA create 'qualityofservice' requests then lead dev, creates scenarios(against which testing is performed) along with all dev tasks required to make meet the request and after arguing with the previous iteration about impact of changes on system. Developers write code against a workitem, and here's the 22 million dollar answer. Check in policy only accepts check in of code compiled against a successful build. Whats in 'the build' you asked, well consider this, multiple developers on the team, limited network bandwidth(everyone on the team in cluding all the other teams at the office using the dev server that carries the database) not to mention power-failures(yes, africa truly is literally the 'dark continent' and we are not refering to skin color here we mean the power grid literally 'fails' randomly with no warning at all). In a nutshell our team works locally...yes...you got it (local) sql server. 'The build'runs a numerous scripts that can...create the database locally(even with multiple user changes to procs, triggers etc!)...create master data...generate test data...keep track of changes affecting migration(schema & data)...recompiles source code against code analysis(rules are rules - a pain in the sphincter muscle but the guys doing maintenance have loved its appearance) deploys reports...webservices...and if you ask erally nicely will set-up the perculator for morning coffee and put the lights out when the last person leave the building...if there hasnt been a power failure that is! Multiple developers all doing there own thing with minimal control over the codebase or worse no control is pure folly. The tool assists developers to propogate their changes across the dev environment ensuring standards are met in the process - do you really want each person to have to track which version of code resides in what folder exactly and on top of that trust the bloke to copy the correct version into a 'last minute' build folder...without overwriting changes made by someone else on the team, and expect it to work first time out the gates? Its complete madness! Who was it that said 'managing developers is like herding cats!!!' Dev is closed only after testing signs off, then deployed to staging server for pre-UAT testing. Even with our current system, 40-50% of dev task get sent back to the developer; thats with source control mind you. Even after the first round comes back fr