Hi pals...
I have been into web development for over 2 years now and have worked in quite a number of projects.
Out here, there is a particular hierarchy to the way in which projects are exercised. To be to the point, what we do is send our client an update on the project on a weekly on biweekly timeline. and we send project updates in the form of what we call a 'Updates'. Currently the whole process is manual and it is the task of project leaders to check out the different changes that have been made in the different modules of the project, pick them up, zip them and send them over to the client. We do have a set of yardsticks that we follow in the creation of these 'Updates'.
Since this manual process of creating the updates was pretty longplaying and time-consuming, What I am currently looking at is automating this whole process of creation of 'Updates', so that all the project leader might have to do is essentially set the different specifications and click on a button and the 'Update' is created (following the different standards) and mailed/ftped to the client.
Heres how I plan to go ahead:
1. There is this 'Update' naming convention that we follow (essentially numbering our updates), and I am looking at maintaining such parameters as the 'update number', 'different email ids to send the update to', the 'host FTP info' etc. in a flat file (say an ini), from which I would pick up the different global parameters.
2. Make a simple UI where the PL would specify other parameters as the physical path of the source code, the update type - full (or) partial, and other related information.
3. If the partial update is whats chosen, I would look at picking up only the files that have been modified since the last update by looking at the 'archive attribute' of the file. If the archive bit is set (true), then the file has been modified since the last update. If the archive bit is reset (false), then the file has not been modified since the last update. If there are files that the PL decides not to send, all he would do is reset the archive bit for that file and it wouldn't be picked up.
4. Once the files have been picked up depending on the different parameters, I would zip them using the command-line option of the WinZip program to create the zip file.
5. The Zip archive would then be mailed to whoever concerned(picked up from the spec file... the ini), FTPed and the update number in the spec file would be updated.
This whole process is fairly square and straight-forward. I would request you to kinda validate this approach and also throw in your suggestions that would help me create a more full-bodied utility.
Thanks for all the comments and suggestions that are on its way.
Sham aka boolean... be practical/be straight... true/false?!
I have been into web development for over 2 years now and have worked in quite a number of projects.
Out here, there is a particular hierarchy to the way in which projects are exercised. To be to the point, what we do is send our client an update on the project on a weekly on biweekly timeline. and we send project updates in the form of what we call a 'Updates'. Currently the whole process is manual and it is the task of project leaders to check out the different changes that have been made in the different modules of the project, pick them up, zip them and send them over to the client. We do have a set of yardsticks that we follow in the creation of these 'Updates'.
Since this manual process of creating the updates was pretty longplaying and time-consuming, What I am currently looking at is automating this whole process of creation of 'Updates', so that all the project leader might have to do is essentially set the different specifications and click on a button and the 'Update' is created (following the different standards) and mailed/ftped to the client.
Heres how I plan to go ahead:
1. There is this 'Update' naming convention that we follow (essentially numbering our updates), and I am looking at maintaining such parameters as the 'update number', 'different email ids to send the update to', the 'host FTP info' etc. in a flat file (say an ini), from which I would pick up the different global parameters.
2. Make a simple UI where the PL would specify other parameters as the physical path of the source code, the update type - full (or) partial, and other related information.
3. If the partial update is whats chosen, I would look at picking up only the files that have been modified since the last update by looking at the 'archive attribute' of the file. If the archive bit is set (true), then the file has been modified since the last update. If the archive bit is reset (false), then the file has not been modified since the last update. If there are files that the PL decides not to send, all he would do is reset the archive bit for that file and it wouldn't be picked up.
4. Once the files have been picked up depending on the different parameters, I would zip them using the command-line option of the WinZip program to create the zip file.
5. The Zip archive would then be mailed to whoever concerned(picked up from the spec file... the ini), FTPed and the update number in the spec file would be updated.
This whole process is fairly square and straight-forward. I would request you to kinda validate this approach and also throw in your suggestions that would help me create a more full-bodied utility.
Thanks for all the comments and suggestions that are on its way.
Sham aka boolean... be practical/be straight... true/false?!
well, our end users might just be the client themselves atleast when it comes to the Update creation utility. And I dont think we can ask them to create and download there own version of the 'Update'... against the etiquettes???