( en | de | ru )

 

  2. tag
  3. ALM development

bookmarks  4

  •  

    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.
    14 years ago by @gresch
     
      almbinaryclientdevelopmentframeworkssoftwaretoolsupdateupgrader
      (0)
      copydelete
       
       
    •  

      Software Release Manager is a simple tool for managing your software releases.
      14 years ago by @gresch
       
        almdevelopmentreleasesoftwaretaggingtools
        (0)
        copydelete
         
         
      •  

        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.
        15 years ago by @gresch
         
          almcode-analysisdevelopmentgoogle-codelifecyclereviewsoftwaresvntools
          (0)
          copydelete
           
           
        •  

          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.
          15 years ago by @gresch
           
            almcollaborationdevelopmentqualityreviewscmsoftwaretools
            (0)
            copydelete
             
             
          • ⟨⟨
          • ⟨
          • 1
          • ⟩
          • ⟩⟩

          publications  

            No matching posts.
          • ⟨⟨
          • ⟨
          • ⟩
          • ⟩⟩