Python, like many other popular OSS (Git anyone?), does not support symbolic links on Windows platforms , although they have been around since Windows Vista. Note, I am referring to actual symbolic links, not NTFS directory junctions or shortcuts.
I’m not really sure why is that. Maybe because they do not distinguish between different Windows revisions?
My current approach is to use the OS commands to create/delete symlinks. It’s not very elegant but it works without compatibility issues, unlike other solutions (calling win32 api through DLLs, manipulating file attributes, and other stuff you find in StackOverflow or tech blogs)
For example, to create a symbolic link of directories, one can use:
child = subprocess.Popen(['MKLINK', '/D', link, target], stdout = subprocess.PIPE, stderr = subprocess.STDOUT, shell = True)
streamdata = child.communicate()
And check child.returncode for the result (and the output – stdout and stderr combined – available in the streamdata variable)
To remove a symbolic link to a directory, use the windows RMDIR command (os.rmdir or os.unlink won’t work)
InstallScript provides a built in SelectDir() function, allowing the user can select a directory. However there is no equivalent function to allow the user to select a file. Which is a problem if you want to implement custom dialogs that browse for files (e.g. a dialog that asks for a .pfx certificate file and its password).
As it happens, InstallShield provides a very good knowledge-base article about how to add such functionality, but it is very-well hidden; you have to use very specific keywords in order to find it… So, to save you some time – go ahead and use this link.
We spent the last year or so building and maintaining a Continuous Integration (CI) system for our major development group. And it was incredibly daunting and frustrating, considering we had to build it around a legacy and problematic version control system like ClearCase Base.
In the textbooks it seems pretty simple: every commit (check-in) to the repository triggers a build, which in turn checks out the latest version of the repository from source control, and run the build process. This way, if a build fail, you know exactly who broke the build – the person who performed the last commit – and if it the build passes, you have full traceability between the build artifacts and the source code they were built from.
Now, let’s try that with ClearCase Base.
This is a question that I get asked from time to time, usually after someone who is not familiar with the deployment world encounters problems with a certain installation. “We could just write a script that extracts the files to the right place, what’s the big deal?”
Well, it’s a big deal. Generally speaking, an installation framework (compared to a script) provides a lot of benefits, such as:
- Modelling the application deployment into sub-modules – allowing to add or remove parts of the applications, define dependencies etc.
- Built-in support for many deployment actions – from simple things like copy files, edit text files, or run some OS command, to configuring web servers and databases
- Ability to rollback each action – which gives you the ability to rollback changes in case of installation error, and provide an uninstaller, with (theoretically) no additional effort.
- Built-in detection of files in use, including the ability (in some cases) to replace such files (upon reboot, or by automatically restart the interfering process)
- Various levels of UI (from completely silent deployment to a full user-driven interface)
- Versioning and update management (upgrades/patches)
- Built-in logging
- Integration with the Operating System software management tools (such as the ‘programs and features’ in Windows)
- And more… (your comments are welcomed)
So, it’s so great, so why not everyone love it?
Today I attended the Jenkins User Conference, held in Israel, hosted by JFrog.
First off I have to say the event was very well organized. Great location, everything on schedule, no technical issues, some nice swag, and excellent food and drinks throughout the day (including afternoon beer!). Considering there were about 450 people there, that is no small task…
The guest of honor was Kohsuke Kawaguchi (KK), the creator of Jenkins, who gave an interesting keynote, with overview about the concepts behind Jenkins 2.0, and some anecdotes from the history of Jenkins.
The main theme of the conference was that Speed is Everything, as you can figure from JFrog’s motto, “Release fast or die”. Their view is that software today is about continuous update – you basically deploy your products once, and from there onward you struggle to update them as often as possible, as seamlessly as possible, without negative effects on the user experience. This raises numerous challenges which various vendors and open source projects are striving to solve.
There conference was packed with sessions related to the DevOps world, mostly about making things faster without losing control on the process. Liveperson, for example, discussed how they manage 6000 releases a year, with over 10K builds per week.
A useful feature of git merge is the –no-ff flag. What it does is always generate a merge commit, even if it was a fast-forward (trivial) merge.
The main point of using this feature is avoid losing information about the historical existence of a certain branch, and (to some degree) being able to associate commits with the branches they were created on.
Turns out, this feature existed in Team Explorer for quite some time, but you would never guessed it if you didn’t stumble upon this User Voice entry.
By unchecking the “commit changes after merging” option, you’ll prevent a fast-forward merge and have the ability supply a custom commit message.
Why not just call it ‘prevent fast-forward merge’? 🙂