Chef is a systems integration framework, built to bring the benefits of configuration management to your entire infrastructure. With Chef, you can:
* Manage your servers by writing code, not by running commands. (via Cookbooks)
* Integrate tightly with your applications, databases, LDAP directories, and more. (via Libraries)
* Easily configure applications that require knowledge about your entire infrastructure ("What systems are running my application?" "What is the current master database server?")
Upgrader is a simple Java-based tool that enables applications developers to add software upgrade capability into their applications. An upgrade process typically involves replacing the old version of the binaries with new version of the binaries and performing data upgrades. It may also need to perform changes to the directory structure. The data upgrade outlined above may involve changes to the configuration files and/or database changes if the application uses a database. This tool provides framework using which application developers can keep track of changes to the application. Every time, there is a change in the database schema or configuration files, the application developers can create a "patch" script and add it to the "patch list". The Upgrader tool may be bundled with the application and is typically invoked during the installation/upgrade. When it is invoked, it determines the current patch level of the system, determines the patch scripts that are needed to be executed, sequence the patch scripts and apply them.
The Software Project Management Solution!
Endeavour Software Project Management is an Open Source solution to manage the creation of large-scale enterprise systems in an iterative and incremental development process. It features support for Use Case management, Iterations, Project Plan, Change Requests, Defect Tracking, Test Cases, Tasks, Document management and many other process artifacts.
So what can you do with Rietveld? The basic workflow is:
1. Developer makes some changes in their Subversion workspace.
2. Developer uploads a patch in the form of svn diff output to Rietveld, using a small script named upload.py. This creates a new issue for them on the Rietveld website.
3. Developer goes to the issue that was just created on the Rietveld site, adds the email addresses of one or more reviewers, and causes Rietveld to send an email to the reviewer(s).
4. Reviewer navigates to the issue on the Rietveld site, browses the side-by-side diffs linked from there. A side-by-side diff shows the old and new version of the source code side by side, with deleted text on the left marked with a light red background, and inserted text on the right marked with a light green background. (Two different shades of red and green each are used, to highlight the differences at a finer-grain level than blocks of lines. This helps find one-character changes and clarifies diffs that just reflow a lot of text.)
5. Reviewer inserts inline comments directly into the side-by-side diffs, by double-clicking lines on which they want to comment. Inline comments are initially created in draft mode, which means that only the comment author can see (and edit) them.
6. Reviewer publishes comments, making them visible to everyone else, and sending an email to the developer (and to other reviewers) summarizing the inline comments with a little bit of context.
At this point, the developer can reply to inline comments directly on the Rietveld website using exactly the same mechanism as used by the reviewer. Replies simply become additional inline draft comments. The developer can also revise their code and upload a new version of the patch. The new version is attached to the same issue, and reviewers can choose to view the diffs afresh, or view the delta between the new and the old version of the patch. The latter feature is particularly helpful for large code reviews that require several iterations to reach agreement between developer and reviewer: the reviewer doesn't have to re-review stuff that didn't change between revisions and was already approved.
Calm stands for…
Seascape Calm Weather
Seascape Calm Weather
…Calm Application Lifecycle Management, which stands for Calm Application Lifecycle Management Application Lifecycle Management … ehm just kidding ;)
Calm is an early implementation of main ALM use cases on an Open Source and collaborative framework based on Apache Maven.
What exactly is Maven Calm
Maven Calm is not just a Corporate POM. It’s a cross-corporate POM which provides lifecycle-oriented configuration for your Maven Plugins; the best way to start is having a look at the presentation! In short, your Project or Corporate POM should look like this to inherit all the ALM oriented behaviors.
For too long, code reviews have been too much of a chore. This is largely due to the lack of quality tools available, leaving developers to resort to e-mail and bug tracker-based solutions.
We've seen a lot of time and energy wasted doing code reviews both in open source projects and at VMware. In both cases, code reviews were typically done over e-mail. A significant amount of time was spent in forming review requests, switching between the diff and the e-mail, and trying to understand what parts of the code the reviewer was referring to.
In an effort to keep our sanity and improve the process both in our open source projects and at companies, we wrote Review Board.
Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It scales well from small projects to large companies and offers a variety of tools to take much of the stress and time out of the code review process.
iston eases your vendor branch management worries. A vendor branch is when you copy a vendor's code (plugins, gems, etc) inside your own repository / project.
What are the advantages of doing that?
* You don't depend on another repository to deploy to your staging or production machines;
* You are insulated from upstream changes, until you really want those changes and have a chance to test them;
* Piston allows you to apply local patches to your vendor code, until the upstream maintainers have applied them.
Release Audit Tool (RAT) is a tool to improve accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. It's reports require interpretation.
RAT was developed in response to a need felt in the Apache Incubator to be able to review releases for the most common faults less labour intensively. It is therefore highly tuned to the Apache style of releases.
RAT is intended to be self documenting: reports should include introductory material describing their function. Building RAT describes how to run RAT. Running RAT describes the options available. The release notes describe the current state of RAT.