When I first heard that Visual Studio 2015 is going to support developing with Python, I wasn’t sure how to react. Microsoft? Python? it just doesn’t seem related. I was very skeptical about working in Python within Visual Studio.
Recently I started a new pet project in GitHub to play around with VS integration to GitHub. So I figured, let’s include some Python code just to see how it feels working with Python in VS.
And it feels great, actually! Visual Studio users would feel right at home with IntelliSense-like auto completion and tooltips, debugging capabilities, unit testing with Test Explorer, advanced searching and editing, and more. I would dare comparing it to some of the best Python IDEs out there like PyCharm. GitHub integration also work seamlessly.
This Python support (a.k.a Python Tools for Visual Studio) is included in the free Visual Studio 2015 Community edition, and even available as open source on GitHub.
Microsoft! on GitHub! Times are changing, indeed.
Netflix are well known for their excellent deployment capabilities.
In this article they go over their build process and tools, from compiling code all the way to production, and presenting their current challenges and future plans.
A highly recommend read for anyone who is interested in doing DevOps the right way.
Inspired by an article on CM Crossroads I stumbled upon lately, I’d like to give a high-level overview on this concept, commonly use in web site developments and can also be applied to cloud applications. But most people (like me) who work with ‘installable’ software never heard of it, and if they did, they regard it as an alien concept that just can’t work.
The short version is this:
- Your software is a service. There is only a single deployment of that software, which means a single relevant codebase.
- Hence there is no point of doing branching and merging in your source control. Everyone commits to the mainline
- Instead of branching, developers wrap every piece of new code with some condition that can be controlled externally (e.g. a flag in a config file, user properties, server environment, etc.)
This way you can “switch versions in runtime”. Which lets you do things like:
- Get rid of feature branches and merges – just deploy the “dark code” (partial/untested code) for a new feature ahead of time and, when the feature is ready, you can easily turn it on (and off if problems appear)
- Roll out an update gradually and selectively
- Rollback an update in a matter of seconds
- Offer different UI experience to different users
- Test new code on production servers (by conditioning based on e.g. user id or IP range)
- And more…
- The code can become somewhat “ugly”. Although many of those flags eventually get removed from the code once they don’t have a use in production.
- ‘config file explosion’ – there are several different approaches regarding controlling the amount and lifespan of configuration flags
- ‘mysterious flags’ – here too, there are some ideas about maintaining proper documentation as well as performing cleanup/refactoring as needed.