Connect to Android with ADB over WiFi

 

image

  1. By default, the Android Debug Bridge (ADB) is configured to communicate with an Android device via USB. It is possible to to reconfigure it to use TCP/IP instead of USB. In order to do this, both the device and the computer must be on the same WiFi network. To setup your environment to debug over WiF issue these steps from the command line:
    • Determine the IP address of your Android device. One way to find out the IP address is to look under Settings > Wi-Fi, and then tap on the WiFi network that the device is connected to. This will bring up a settings screen showing information about the network connection.
  2. Connect your Android device to your computer via USB.
  3. Next restart ADB so that it using TCP on port 5555. From a command prompt, type the following command: adb tcpip 5555
  4. Disconnect the USB cable connecting your device to your computer
  5. Configure ADB so that it will connect to your Android device on the port that was specified in step 1 above:  e.g. adb connect 192.168.0.12:5555   Once this command finished the Android device is connected to the computer via WiFi.

p.s.

  • When you are done debugging via WiFi, it is possible reset ADB back to USB mode with the following command: adb usb
  • To list the connected device, use the command: adb devices

Manage Azure using Windows PowerShell

image

http://msdn.microsoft.com/en-us/library/windowsazure/jj156055.aspx

  1. Create a self-signed Management Certificate. Open a Visual Studio command prompt(As administrator). Details.
    makecert -sky exchange -r -n "CN=AzureCertificateName01" -pe -a sha1 -len 2048 -ss My "AzureCertificateName01.cer"
  2. Upload Management Certificate to Azure

    To upload a management certificate to Windows Azure, go to the Settings page in the Management Portal, and then click MANAGEMENT CERTIFICATES.

  3. To install Windows Azure PowerShell. Download here.
  4. Set Windows PowerShell execution policy (As adminstrator):
    PS C:\> Set-ExecutionPolicy RemoteSigned
  5. Store Azure Subscription and Certificate locally (Run once) details
    $mySubID = "subscritionID" 
        
    $certThumbprint = "Thumbprint"
    $myCert = Get-Item cert:\CurrentUser\My\$certThumbprint
    $mySubName = "SubscriptionName"
    Get-AzureSubscription
    Set-AzureSubscription -SubscriptionName $mySubName -Certificate $myCert -SubscriptionID $mySubID
  6. Select Azure Subscription
    Select-AzureSubscription -SubscriptionName $mySubName
  7. Store Azure Subscription and Certificate locally
    Start-AzureVM -ServiceName "myCloudServiceName" -Name "myVMServiceName"
        
    Stop-AzureVM -ServiceName "myCloudServiceName" -Name "myVMServiceName"

Continuous Deployment to Azure WebSite from BitBucket, CodePlex, Dropbox, GitHub, or Mercurial

 

image

http://www.windowsazure.com/en-us/develop/net/common-tasks/publishing-with-git/#Step7

  1. After your web site project has been pushed to a repository web site, in the Windows Azure Portal quick glance section, select Set up deployment from source control. The Set Up Deployment dialogappears that asks Where is your source code?.

  2. Choose the source control method that you are using.

  3. When prompted, enter your credentials for the service you selected.

  4. After you have authorized Windows Azure to access your account, you will be prompted with a list of repositories.

    git-ChooseARepositoryToDeploy

  5. Select the repository that you want to associate with your Windows Azure web site. Click the checkmark to continue.

    NOTE

    When enabling continuous deployment with GitHub or BitBucket, both public and private projects will be displayed.

  6. Windows Azure will create an association with the selected repository, and will pull in the files from the master branch. After this process completes, the deployment history on the Deployments page will show an Active Deployment message like the following:

    git-githubdeployed

  7. At this point your project has been deployed from your repository of choice to your Windows Azure web site. To verify that the site is active, click the Browse link at the bottom of the portal. The browser should navigate to the web site.

  8. To verify that continuous deployment is occurring, make a change to your project and then push the update to the repository you have associated with this web site. Your web site should update to reflect the changes shortly after the push to the repository completes. You can verify that it has pulled in the update on the Deployments page of your Web Site.

    git-GitHubDeployed-Updated

How continuous deployment works

Continuous deployment works by providing the DEPLOYMENT TRIGGER URL found in the deploymentssection of your site’s Configure tab.

git-DeploymentTrigger

When updates are made to your repository, a POST request is sent to this URL, which notifies your Windows Azure Web Site that the repository has been updated. At this point it retrieves the update and deploys it to your web site.

Specifying the branch to use

When you enable continuous deployment, it will default to the master branch of the repository. If you want to use a different branch, perform the following steps:

  1. In the portal, select your web site and then select CONFIGURE.

  2. In the deployments section of the page, enter the branch you wish to use in the BRANCH TO DEPLOYfield, and then hit enter. Finally, click SAVE.

    Windows Azure should immediately begin updating based on changes to the new branch.

Gitflow–a Git Workflow designed around Project Release

 

image

http://nvie.com/posts/a-successful-git-branching-model/

The main branches

  • master
  • develop

Supporting branches

  • Feature-*

    May branch off from: develop
    Must merge back into: develop
    Branch naming convention: anything except master, develop,release-*, or hotfix-*

  • Release-*
    • May branch off from: develop
      Must merge back into: develop and master
      Branch naming convention: release-*

  • Hotfix-*
    • May branch off from: master
      Must merge back into: develop and master
      Branch naming convention: hotfix-*


    Git-branching-model.pdf

    Git Workflows Tutorial by Atlassian

     

    1. Centralized Workflow

    If your developers are already comfortable with Subversion, the Centralized Workflow lets you experience the benefits of Git without having to adapt to an entirely new process. It also serves as a friendly transition into more Git-oriented workflows.

    Learn more»

    image

    2. Feature Branch Workflow

    The Feature Branch Workflow builds on the Centralized Workflow by encapsulating new features into dedicated branches. This enables the use of pull requests as a means to discuss changes before they’re integrated into the official project.

    Learn more»

    image

    3. Gitflow Workflow

    The Gitflow Workflow streamlines the release cycle by using isolated branches for feature development, release preparation, and maintenance. Its strict branching model also lends some much needed structure to larger projects.

    Learn more»

    image

    4. Forking Workflow

    The Forking Workflow is a distributed workflow that takes full advantage of Git’s branching and cloning capabilities. It provides a safe, reliable way to manage large teams of developers and to accept commits from untrusted contributors.

    Learn more»

    image