Posts Tagged ‘svn’

InstaDMG Issues, and Workflow Automation via Your Friendly Butler, Jenkins

Thursday, January 17th, 2013

“It takes so long to run.”

“One change happens and I need to redo the whole thing”

“I copy-paste the newest catalogs I see posted on the web, the formatting breaks, and I continually have to go back and check to make sure it’s the newest one”

These are the issues commonly experienced with those who want to take advantage of InstaDMG, and to some, it may be enough to prevent them from being rid of their Golden Master ways. Of course there are a few options to address each of these, in turn, but you may have noticed a theme on blog posts I’ve penned recently, and that is:

BETTER LIVING THROUGH AUTOMATION!

(We’ll get to how automation takes over shortly.) First, to review, a customized InstaDMG build commonly consists of a few parts: the user account, a function to answer the setup assistant steps, and the bootstrap parts for your patch and/or configuration management system. To take advantage of the(hopefully) well-QA’d vanilla catalogs, you can nest it in your custom catalog via an include-file line, and you only update your custom software parts listed above in one place. (And preferably you keep those projects and catalog under version control as well.)

All the concerns paraphrased at the start of this post just happen to be discussed recently on The Graham Gilbert Dot Com. Go there now, and hear what he has to say about it. Check out his other posts, I can wait.

Graham Gilberts Blog
Back? Cool. Now you may think those are all the answers you need. You’re mostly right, you smarty you! SSDs are not so out-of-reach for normal folk, and they really do help to speed the I/O bound process up, so there’s less cost to create and repeat builds in general. But then there’s the other manual interaction and regular repetition parts – how can we limit it to as little as possible? Yes, the InstaDMG robot’s going to do the heavy lifting for us by speedily building an image, and using version control on our catalogs help us track change over time, but what if Integrating the changes from the vanilla catalogs was Continuous? (Answers within!) (more…)

The (Distributed) Version Control Hosting Landscape

Monday, March 19th, 2012

When working with complex code, configuration files, or just plain text, using Version control (or VC for short) should be like brushing your teeth. You should do it regularly, and getting into a routine with it will protect you from yourself. Our internet age has dragged us into more modern ways of tracking changes to and collaborating on source code, and in this article we’ll discuss the web-friendly and social ways of hosting and discovering code.

One of the earliest sites to rise to prominence was Sourceforge, which is now owned by the company behind Slashdot and Thinkgeek. Focused around projects instead of individuals, and offering more basic VC systems, like… CVS, Sourceforge became a site many open source developers would host and/or distribute their software through. Lately, Sourceforge seems to be on the wane, as it is found to be redirect and advertising-heavy.

When Google wanted to attract more attention to its open source projects and give outsiders a way to contribute, it opened code.google.com in 2005. In addition to SVN, Mercurial (a.k.a. Hg) was available as an alternative VC option in 2009, as it was the system adopted by the Python language, whose creator is an employee at Google, Guido van Rossum. Hg was one of the original Distributed Version Control Systems, DVCS for short, and the complexity of such a system could feel ‘bolted-on’ when using Google for hosting (especially in the cloning interface), and its recent introduction of Git as an option mid last year brings this feeling out even more.

Bitbucket was another prominent early champion of Hg, and its focus, like those previously mentioned, is also on projects. Atlassian, the company behind it, are real titans in the industry, as the stewards of the Jira bug-tracking software, Confluence wiki, HipChat web-based IM/chatroom service, and have recently purchased the mac DVCS GUI client SourceTree. Even more indicative of the fast-paced and free-thinking approach of how Atlassian has done business is their adoption of Git late last year as an option for Bitbucket, going so far as to guide folks to move their Hg projects to it.

But the 900-pound gorilla in comparison to all of these is Github, with their motto, ‘Social Coding’. Collaboration can tightly couple developers and make open source dependent on the approval or contributions of others. In contrast, ‘Forking’ as a central concept to Git makes this interdependency less pronounced, and abstracts the project away to put more focus on the individual creators. Many words have already been spent on the phenomenon that is Git and Github by extension, just as its Rails engine enjoyed in years past, so we’ll just sign off here by recommending you sign up somewhere and join the social coding movement!