Breaking a Setup program.
-
We're basically a Java shop. We have a few legacy programs with VB and VB.Net GUI's, but that's about it. I'm kind of light on Java experience (about two years), but I'm one of the few people here with substantial .Net experience (~ 6 years).
I'm on the Kanban team that handles the legacy programs. One of the junior programmers picked up a ticket to modify a program so that the users can run the annual reports without our intervention. He was able to modify the program, but he declined to update the setup program, effectively breaking it by this neglect. The Kanban master (a non-programmer) supported him on this. The junior programmer's solution was to require anyone setting up the program to read a set of instructions that he is writing.
-
The junior programmer's solution
was to require anyone setting up the program to read a set of instructions that he is writingshould be to fix the installer.
Empty cannot be post
-
I'm in a scrum shop. Well, our team is scrum, most of the rest is scrumfall. But should the kanban master even be the one to make that call? Here we're got a definition of done, which is assembled in cooperation with the stakeholders, and any install/upgrade changes are part of that.
-
I'm in a scrum shop. Well, our team is scrum, most of the rest is scrumfall. But should the kanban master even be the one to make that call? Here we're got a definition of done, which is assembled in cooperation with the stakeholders, and any install/upgrade changes are part of that.
Scrum, although it has many, many, many enthusiastic devotees, is not for everyone. Kanban has substantially lighter overhead. Our main project is scrum, our legacy projects are kanban.
-
Are these all like development methodologies based on some hippie book? Ugh
I'm so glad I'm not a dev sometimes.
-
Are these all like development methodologies based on some hippie book? Ugh
I'm so glad I'm not a dev sometimes.We open and close all of our scrum meetings with 16 rounds of the scrum Maha Mantra: "Meetings are good! Individuals are bad! Submission to the process!"
-
Are these all like development methodologies based on some hippie book?
Never go to a conference filled with this sort of people. You'll loose 5 points of INT just after the hand shaking. And what is it required to be a SCRUM master? That you know how to bull-shit, how to play with LEGOSâ„¢ and with cards. The only place I worked with that did 100% SCRUM went down the drain two years ago.
Want an example of the level of bullshit this is? There are "implementations" of SCRUM for HR, marketing and other stuff completely different from programming.
The only good thing about this is that at now software projects are seen as evolving beasts.
-
Both Kanban and Scrum are slightly altered "do what the fuck you want" methodologies. They're not that bad.
-
Right, the meetings... I think this is why PM's love this so much. Between the dailies and the retrospectives they have billed for half of their time.
-
Right, the meetings... I think this is why PM's love this so much.
Who doesn't? I love to get paid for drinking coffee. And when a meeting becomes boring, I can still pull out my laptop and post here.
-
SCRUM meetings are not like that. You have to do the cards thing, and then use post-it's to write stuff and then discuss the stuff you wrote on the post-it's and then... ugh!!!
-
Who doesn't? I love to get paid for drinking coffee. And when a meeting becomes boring, I can still pull out my laptop and post here.
-
We sync with PM for an hour every 3 weeks. I don't think we've done retrospective for a year or more. Daily scrum tends to run long since the last reorg, because a lot of other relevant discussion sneaks into it. There are times when the 10:30 daily scrum ends up getting truncated by lunch at 12:00.
We consider it productive though - a lot of planning and evaluating what the other team (in Shenzen) did winds up in that meeting as well. And it's at our desks, so you can do the tdwtf thing too, or do some work, if talk turns to a less interesting topic.
-
Are the instructions 3 steps, or 300 steps? That's really the information I need to judge this.
If the installer did nothing but, for example, install the VB6 runtime then copy the application's files, I'm actually ok with this. Honestly. The time taken to fix the installer will probably never be regained by the time taken to do a few manual installs until the program's retired.
If it's .net, replace the old installer with the Click-N-Run installer you can literally make in about 2 minutes. It's more than sufficient for a project like this, and even supports update checks. Problem solved.
The biggest offense here, IMO, is not fixing the installer but also not removing it. Because if it doesn't work, you shouldn't be building and distributing it.
-
So... building an installer is not automated? That's a WTF right there.
I've used the Visual Studio setup projects a few time and it never was anything more than "drag project into setup project, click build, take MSI."
-
So... building an installer is not automated? That's a WTF right there.
I've used the Visual Studio setup projects a few time and it never was anything more than "drag project into setup project, click build, take MSI."
The junior programmer did not even take a few minutes to see if that's all it is.
-
"drag project into setup project, click build, take MSI."
How do you automate that? Stupid IDEs and stupid SDKs and stupid click&drag processes.
There are times when the 10:30 daily scrum ends up getting truncated by lunch at 12:00.
That's not SCRUM, that's a meeting you do every day.
-
How do you automate that? Stupid IDEs and stupid SDKs and stupid click&drag processes.
The Visual Studio Setup projects are really that simple: create a project, select the things to include (the primary output of your projects, dependencies, where to create shortcuts) and you're done. You can't do much custom stuff with those projects, but if you have a simple .exe it gets the job done pretty well. If you need custom stuff to happen during installation, you could take a look at a product such as Advanced Installer or InnoSetup.
Anyway, you should be able to integrate the creation of an installer with your CI pipeline. F5 is not a build process and a 300 step manual does not equal a good deployment methodology.
-
Kanscrufall is fun too!
-
Visual Studio setup projects were removed in Visual Studio 2012 with vague advice to use WiX, which comes with a cluster of WTFs; yes you can build proper MSIs with WiX but it will drain the life force from your soul.
MS grudgingly released an extension to build the old setup projects again that sort of works with VS2013 a couple of years later, but it's abandoned and buggy.
Visual Studio setup projects (vdproj) will not ship with future versions of VS
[UPDATE 04/18/14] The Visual Studio team has released an extension to VS 2013 to address the feedback on this, which has been loud and clear for a long time now: Visual Studio Installer Projects Extension. [UPDATE 11/6/12] Fixed broken links. At the user group meeting last night,
Visual Studio Installer Projects Extension - Visual Studio Blog
UPDATE 6/12/2014: We have released the final version of this extension – v1.0.0.0. This release addresses: Warnings when building with Microsoft.bcl.async Error 2727 occuring with more than 1 content file Some cases of the 0x8000000A when using the command line Unfortunately we couldn’t address all...
-
What about waterfragilescumfall?
-
Only one guy in our team went to scrum training - his main takeaway was 'do what works for you'.
We've dropped a bunch of things we used to do (like extensive planning sessions and planning poker sessions) as the team shrunk.
One notable thing from the greater team last summer was an email - "Please remember to enter the ERs you will be fixing each sprint up till November". We had a laugh.
-
The old setup projects aren't maintained anymore, indeed, but overall they work well. If you want something which is still maintained, Advanced Installer and InstallShield LE are alternatives.
Wix is not a tool, it's an instrument of torture.
-
Wix is not a tool, it's an instrument of torture.
Only because you really have to understand MSI itself...
I've been using WiX for years with no issue - when I was at VMware, we were in the process of converting most of our InstallShield projects to WiX.
-
I ran once into a hitch where click once forget to include two system libraries, which where included into the actucal buld just fine. Took me days to find out why my program run fine on my dev pc, but crashed when installed. I finally resolved this by adding both dlls manually to the project.
For complicated setups I like wix installer, it's free and powerful. The documentation is shit, though - typical open source. Also the name is hilarious, I am a german and wix almost sounds like a slang for jerking off or maybe the result of jerking off.
-
So... building an installer is not automated? That's a WTF right there.
TRWTF is that the OS doesn't come with a standard installer that simply installs packages instead of packaging the same automatically (or worse, manually) generated code with fucking everything. It's not exactly an unheard-of concept.
-
Also the name is hilarious, I am a german and wix almost sounds like a slang for jerking off or maybe the result of jerking off.
You beat me off to it :p
-
TRWTF is that the OS doesn't come with a standard installer that simply installs packages
AppX packages in Windows 10 :)
-
NSIS. Nuff said.
-
How in the
do you break an installer by updating a program? Did 
rename the output executable or was this just code-modifications?Side-
: Wonder how much I could sell a VS extension that provided a GUI for WiX that compared to InstallShield/AdvancedInstaller/NSIS. InstallShield/Flexera is complete fucking  but if all the installer needs to do is covered by MSI Standard Actions it IS pretty user friendly.
-
13 posts were split to a new topic: Wix Wankery
