In the past my development team we have mostly done waterfall development against an existing application and deployments were only really done towards the end of a release which would normally result in TEST, UAT, PROD releases normally only consisting of three to five releases in a two month cycle.
A release was an MSI installer, deployed via Group Policy.
We have now moved to a more agile methodology and require releases at least once per day for testing, some times more often.
The application is a VB6 app and the MSI was taking care of COM registrations for us, users do not have elevated privileges on their machines.
Does anyone have any better solutions for rapid deployment?
We have considered batch/scripted installs of the MSI, or doing COM registrations per file, both using CPAU for elevated privileges, and ClickOnce. Neither of these have been tested yet.
Edit: Thanks for suggestions.
To clarify, my pain point is the MSI build / deployment process takes a long time can take up to two hours to get the new build on to the testers desktops. The testers do not admin rights on their machine (and will not get them) so I am looking for a better solution.
I have played around with ClickOnce, using a dot net wrapper which starts up the application and has all the OCX/DLL vb6 assemblies as isolated dependencies, but this is having issues finding all the assemblies when it starts up, or messages to that effect.
CruiseControl and Nant are probably your best bet for builds with flexible output. But Rapid Deployment?
My concern is that you are looking at the daily builds in the wrong way. The dailies do NOT need to be widely deployed. In fact, QA and Development are the only ones who should care about the builds on a day to day basis. EVen then, the devs shouldn't be out of sync ;).
The customer team should only recieve builds at the end of a iteration. That is where you show them what you have done and they provide feedback and you move forward from there. Giving them daily builds could cause a vicious thrashing that would kill your velocity.
All that being said, a nice deployment package might be good for QA. But again, it depends on how in step they are with your development iterations. My experience, right or wrong, is that QA is one iteration back testing the deliverables from the last iteration. From that point of view, they should be testing with the last "stable" release as well.
Is this something you can do in a virtual machine? You could securely give your testers admin rights on the virtualized system and most virtualization software has some form of versioning so you can roll back to a "good" state if something goes wrong. I've found it to be very useful for testing.
I'd recommend ClickOnce with the option to update on execution. That way only people using the software receive and install the updates.
You could try registry-free COM. See this other question. ActiveX EXEs still have to be registered though.
EDIT: to clarify, using registry-free COM means the OCX/DLL components you mention don't need to be registered. Nor do any OCX/DLL components they use. You can just copy the whole application directory onto a tester's machine and it will work straightaway.
If I understand your question correctly, you need admin rights to install your product. I see three options:
1) Don't install to the tester's desktops. Get some scratch testing machines (as dmo suggested, VMWare might help) that you can safely give them admin rights to. This may mean giving them a test domain and their own group policy to edit.
2) Build a variant that doesn't require MSI installation, and can be executed directly. Obviously your testers would not be testing the deployment and installation process with this variant, but they could perform other tests of the product's functionality. I don't know if this is possible with your product; it would certainly be work.
3) Take your agile medicine: "[prefer] responding to change over following a plan". That is, if denying admin rights to your testers is interfering with their ability to do their jobs efficiently, then challenge the organization to give them admin rights. (from experience, this will mean shifting to #1, but it might be the best way to make the case). If they are expected to test the product, how can they not even be allowed to install it in the same way a customer would?
If the MSI deployment is taking velocity out of agile testing, then you should test MSI deployment less regularly.
Use XCOPY deployment wherever possible, using .local for COM components. This can be a problem with third party components. As third party components are pretty stable, you should be able to build a custom MSI for these, install them once and be done with it.
You should try an automated build/deploy process or script that you can manually run. Try Teamcity or CruiseControl. Good luck!
I'm not sure just precisely what your pain point is.
You specifically mention registration of VB6 COM objects. Does the installer sometimes fail because of that?
Is it that the installer works but people don't know to install the new build so they are more often than not reporting bugs on an old build?
If the former, then I suspect the problem to be that VB6 was very likely to play fruit basket turnover with the GUIDs when rebuilding the solution. Try recreating your public interfaces in MIDL and have your VB6 classes implement those interfaces.
If the later, then try Microsoft's SMS product. No, it has nothing to do with cell phones. If all the user's aren't on the same domain, then you will have to build an "auto update" feature into your product. Here is a third party offering that I've heard of but never used.
I'm using SetupBuilder (http://setupbuilder.com/products_setupbuilder_pro.htm) for all my builds. Very extensible. Excellent support.
Not sure exactly if it fits your needs, but this kind of post on the forums, "Installing as a limited account user (non-admin) on XP" (http://www.lindersoft.com/forums/showthread.php?t=11891&highlight=admin+rights), makes me think it might be.
Related
I develop Windows desktop applications.
Several times a month we have to create one installer for a department of about 400 people, and each time we have to place the installer we are responsible for on the file server, receive installers from other teams, make sure the version number is correct, create information materials for our members, and notify the installer creation team.
I check to make sure that the number of versions is correct, prepare information materials for the members, and notify the installer creation team.
These tasks are tedious because they involve a lot of mistakes by myself and others, take a lot of times, and require a lot of attention.
I would like to reduce the manual work.
Is there a better way?
In addition, we are using TFS and Azure DevOPS for code management.
(We are in the process of transitioning from TFS to Azure DevOPS, so it depends on the team which one they are using.)
Are there other things out there like ClickOnce, but that use the actual application files?
I am finding the signing and packaging process very difficult to pass off to others.
I have tools than can make an MSI. But the deploy process of ClickOnce is very useful.
Is there something out there that works like ClickOnce but uses an MSI?
NOTE: I need what ever I use to not require the help of my System Admins. They are in a different structure of my company and rolling out my releases via them would delay things too much. (This means that using a Group Policy is not feasible.
Installshield has in their Premier and Professional editions has a feature that will check for updates before each execution, just like a ClickOnce application, which sounds like just what you are asking for. However, the price is not cheap.
http://www.flexerasoftware.com/products/software-installation/installshield-software-installer/tab/features
Requirement: install a Windows Store app without requiring the user to nav to the store and click Install. Perhaps a batch file. Perhaps a Powershell script. Perhaps something else.
This is not a side-load question; this is a public, Windows Store question
Scenario 1: Maybe, my company has a new app in the Store that I want to push it out to every single employee without requiring them to nav to the Store and click Install.
Scenario 2: Maybe, my company has just subscribed to online CRM (or something) and I want to push out the CRM client to every single employee without requiring them to nav to the Store and click Install.
Scenario 3: Maybe, my company is hiring new employees & preparing new computers. In their first-time login script (or something) I want to ensure they have the Apps important to my business - without requiring they nav to the Store and click Install (perhaps several times).
Scenario 4: Maybe, my company is very virtualized, and we provision new VMs all the time. The VM performs fine, but bandwidth is our problem. To streamline the user experience, users logon and watch as the VM prepares itself for them by downloading and installing Windows Store Apps for them.
Please don't pick on the scenarios, I am just trying to give a possible use case.
Complication: I have been told (by people who know this sort of thing) that there is no built-in API to accomplish this. But we are developers. Nobody dares tell us something is impossible. But, if there isn't a built-in API, how could a network administrator or developer on a team solve this problem? I realize this question is somewhat brainstorming. But it gets asked over and over and over and over. I would like to provide a resource for others who might be considering the same scenario.
Hey, perhaps this is easy. Please share.
We have SCCM in our environment and some PS scripts are deployed in C:\Windows\CCM\SignedScripts that may be worth investigating. They are not SCCM specific. The most relevant of the three is "C:\Windows\CCM\SignedScripts\installwindows8app.ps1". The script just passes parameters to Add-AppxPackage though I am not sure how it would get the path to the .appx in the MS store.
You can get the location of installed apps on a model machine with (Get-AppxPackage -Name "*").InstallLocation but then you would need to repackage, store, deploy, and maintain them--not really the solution you were looking for.
Between investigating how SCCM would do it with these scripts and digging in the installed apps, maybe someone runs across something.
Almost 8 years into the future and we are getting closer to an answer!
Recent versions of Windows 10 now come with "winget" and they've added some Microsoft Store support.
It seems hit and miss as to what apps I can install. Using Spotify as an example,
winget search "Spotify"
Probably best to install via id instead though:
winget install 9NCBCSZSJRSB
Since it stops and asks if you want to agree to the terms and conditions, you answer automatically via:
echo Y | winget install 9NCBCSZSJRSB
As one of my references states: "What’s interesting is that if you have the Microsoft Store open at the same time as running winget install, you’ll see the install progress updating in real time in both the command line window and the Store GUI."
There is plenty left to be desired with this answer since most automated installs will probably just run into the error "Verifying/Requesting package acquisition failed: no store account found". But, if you're able to run it as the user, you might have some more luck. I'd love to see this tool get more finished so it can actually accomplish all the scenarios you listed. As Microsoft updates the tool, we could update this answer accordingly.
References and notes:
There's also the unlisted option --scope user or --scope machine found via: https://aka.ms/winget-settings
This page was helpful in my discovering of the tool: https://petri.com/how-to-programmatically-install-microsoft-store-apps-using-windows-package-manager
If you want to change and compile winget on your own, the source is here: https://github.com/microsoft/winget-cli/
Isn't this what Intune is for? http://www.microsoft.com/en-us/server-cloud/products/windows-intune/default.aspx#fbid=CFXRSOlwIM2
I've been developing a web app locally on my local MAMP computer for the last few months. Now I am ready to launch it while continuing to add enhancements/fixes. So, I am wondering what is a good way to implement a development AND production server in order to efficiently manage updates, prevent overwrites, and seamlessly add other developers into the workflow. I also want something that has a minimal learning curve for me. Personally, for whatever reason, I've never been able to fully grasp version control systems like Git or SVN so I am hoping for an easier solution until I am able to invest more info the business.
As I see it, the options that I have are:
Spend more time learning Git before launching. And hoping that I don't break anything while further developing my app.
Buy two hosting accounts. One for Dev and one for Prod, where only I can do the deployments into Prod. I suppose I'd have to keep track of all files we've modified in a spreadsheet that are deemed ready for deployment.
Editing right on the FTP (no Dev server).
Are there any other options that you can recommend? I've heard that there are some new types of Web Hosting companies that can do the heavy lifting...
While personally, I have had good experiences using svn/git for multi-developer websites, I can understand your reticence to start relying on something you are not entirely familiar with. Unfortunately, I do believe that is your best option, but failing that, you might try using subdomains. My former employer would create test area on the disk and point beta.thedomainname.com at it. When bug fixes or upgrades were complete and verified to be working in the beta directory, the entire directory would be copied over to the live domain. Not the most elegant solution, but it worked. It certainly is cheaper than buying two hosting accounts.
A year ago I started to create some automated builds on our build machine (TFS2008). Not so much for combining with full scale TDD (we still have a lot of old legacy code), but for being able to detect at an early stage if builds got broken. Another objective was also to minimize the packaging/deployment work.
This has been working quite well so far, but lately some coworkers are starting to treat the buildserver as a goldmine of quick releases, and the testing process seems to get less priority more often. Refactoring some of our code during 2-3 days proved that the builds on our buildserver potentially could reach our customers. :)
I guess our buildserver over time has shifted from being a 'consistency tool' for the developers, into being a server producing packages that is expected to be release quality 24/7.
This is clearly a communication problem, and there should be a set of rules on this. Only problem is that I don't know where to begin. Does anyone have similar experiences with this?
You're correct, it is a communications problem. If your developers and management are expecting release-quality builds all the time, they're not understanding the process of build/test/release.
The only thing you can do is clarify the purpose of a build server: a single, centralized location for builds. You need to clarify the distinction between a build and a release. Builds should always succeed (no one should break the build) but the ability to create a build does not have any bearing whatsoever on build quality or the suitability of a given build for release.
Build quality is measured by unit, functional, and user acceptance testing. There is no replacement for these tests in preparing a build for release. The long-term costs of not doing these tests far outweigh the short-term benefits of getting a release out the door.
Our unittestserver does tests, and tags CVS. Then we go on a buildserver which has ea script to create a release which isready for customer installation. This release is then installed on a test server as if it was the customer's server, and then tested.
Judging your story, you are hoping to find some script or setting which will prevent the buildserver from getting used as "quick release" server. The only real way to do this is process.
Rules in our company:
Developers check into CVS, they get mails from the unittest server if it fails, and have to fix that in code. No access to the build/test server for devs.
There is 1 specific developer who can create a release which he can send to the test department.
The test department installs the release on their test server and tests it.
The testers, and only the testers, can give a "Go" for release.
The release is done by a designated person who is also the customer contact.
As you can see the developers are seperated from the testers and the customer (formally speaking). In practice it is not all that rigid ofcourse, but people need to understand that if this process is not in place, the customer will get inferior quality software.
The customer has to be educated that "fast" means "low quality". We can do it Fast, Good, or Cheap. Pick two.
http://www.sixside.com/fast_good_cheap.asp
I suggest that all builds created by the internal build server state in the splash screen "INTERNAL BUILD - NOT FOR CUSTOMERS", and the release build server plops in the official splash screen.