Hi friends,

Recently I was working in Shell script to replace a content of a file. I have used powershell for windows and shell for mac. This is specific to my build server. I was facing one peculiar issue with sed command usage.

Command Used: sed – i ‘s/oldString/newString/g’ filename

Error: sed: 1: invalid command code J on Mac OS

Though i extension is optional in ubuntu, in mac its mandatory to give it. refer the below highlighted screenshot.

To solve this, I just gave a Empty string Extension like sed – i “”  ‘s/oldString/newString/g’ filename. Voila it solved the issue.

I found it hard to solve this issue as I didnt get any clear pointers. So I thought of creating the page,so it will be helpful for developers.

Sometimes in our project, we may need to trigger sequential jobs possibly to avoid manual starting of jobs. I too has similar issues and I was looking for multiple forums in this regard. I have collected the necessary information required for this job and posted in this blog.

Option 1: Use existing Jenkins Feature

• Click Customize your jenkins job
• Build Triggers > Build after other Projects are built.

you can mention which projects needs to be watched and you have multiple options such as

1. Trigger only if the build is stable
2. Trigger even if the build is not stable
3. Trigger even if the build fails

This avoids multiple dependent projects not to be triggered if you select option 1.

Option 2: Parameterized Trigger Plugin 

• Create a wrapper job for your sequential jobs
• For each sequential job
  • Select Build->Add build step->Trigger/call builds on other projects
  • Enter the sequential job name
  • Check the ‘Block until the triggered projects finish their builds’ checkbox (this only appears when you have the Parameterized Trigger Plugin installed)

Now when you run the wrapper job, all the triggered jobs will be run in order and sequentially. You of course also have the option of using the parameters functionality of the plugin too.

Personally, I have used Parameterized Trigger Plugin has it provides lot of Functionality.

Reference: https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

Option 3: Build Pipeline Plugin

• Gives the ability to form a chain of jobs based on their upstream\downstream dependencies. Downstream jobs may, as per the default behaviours, be triggered automatically ,or by a suitable authorised user manually triggering it.

Reference: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

Option 4: Downstream –Ext Plugin

This plugin supports extended configuration for triggering downstream builds:

• trigger build only if downstream job has SCM changes
• trigger build if upstream build result is better/equal/worse than any given result (SUCCESS, UNSTABLE, FAILURE, ABORTED)
• for Matrix (alias multi-configuration) jobs you can decide which part of the job should trigger the downstream job: parent only, configurations only or both

Reference: https://wiki.jenkins-ci.org/display/JENKINS/Downstream-Ext+Plugin

Alpha and Beta Testing

It’s always valuable to get real-world feedback from users, especially before launch. Google Play makes it easy to distribute pre-release versions of your app to alpha and beta test groups anywhere in the world.

In the APK section of your Google Play Developer Console you’ll find the Alpha Testing and Beta Testing tabs. Here you can upload versions of your apps’ APK files and define a list of testers as a Google Group or Google+ Community. Once this is done you’ll receive a URL that you forward to your testers, from which they can opt-in to the testing program.

After opting-in, your testers then go to your app’s product page and when they download the app Google Play will deliver them the alpha or beta version as appropriate. Incidentally, if a user happens to be opted-in to both your testing groups, Google Play will always deliver them the alpha test version.

Note that users cannot provide feedback and reviews on alpha and beta versions of your apps. To gather feedback you could used the Google Group or Google+ Community, or setup an email address or your own website.

You can use these testing programs to optimize your apps, help with rollout to new markets, and start building your community. There is also more information on using beta test in the Launch Checklist and Localization Checklist.

Use alpha/beta testing

Using the Google Play Developer Console, you can select groups of users to alpha/beta test different versions of your app and gradually roll out an app update over time, known as a staged rollout.

Set up an alpha/beta test

With the alpha/beta testing tools available in your Developer account, you can test different versions of your app.

• You don’t need a production APK to publish an alpha/beta app.
• If you’re testing an existing app that you’ve published before, only users in your test group will receive an update for your Alpha/Beta version. If you’re testing a new app that you haven’t published before, only users in your test group can find and download your app.
• After publishing an alpha/beta APK, it may take up to 24 hours for your test link to be available to testers.
• If you make any changes to your app’sPricing & Distribution page, including setting your app price to Paid or Free, it affects your production, alpha, beta, and any future versions of your app.

Note: When you’re starting a new alpha/beta test, it’s a good idea to start with a small group of alpha testers, then expand your test to a larger beta test group.

Step 1: Add an APK to your alpha/beta test

1. Sign in to yourGoogle Play Developer Console.
2. Click All applications.
3. Select an app.
4. On the left menu, clickAPK.
5. Near the middle of the page, click theAlpha Testing or Beta Testing
6. Click theUpload
7. Select your APK file.
8. Select thePublish

refer below screenshot for Beta & Alpha Besting,

reg the difference between Alpha and Beta testing, refer Q&A section at end of document.

Step 2: Select a test group

If you haven’t already made one, you need to make a Google Group or Google+ Community that includes people you want in your alpha or beta test group. Once you’ve made a Google Group or Google+ Community, you can add it to your list of testers on your Developer Console.

Note: If a user is eligible for both alpha and beta versions, they’ll receive the alpha version.

Here’s how you add your Google Group or Google+ Community to your list of testers and share a link to your app.

1. Sign in to yourGoogle Play Developer Console.
2. Click All applications.
3. Select an app.
4. On the left menu, clickAPK.
5. Near the middle of the page, click theAlpha Testing or Beta Testing
6. Under “Alpha testers” or “Beta testers”, clickManage list of testers.

7. Type the Google Group email address or Google+ Community URL.

Note: When you add a test group, make sure to use the following formats:

Google Groups: yourgroupname@googlegroups.com

Google+ Community: https://plus.google.com/communities/123456789012345678901

8. ClickAdd.
9. Copy and share the displayed URL link with your testers.
   • The link uses the following format:https://play.google.com/apps/testing/com.package.name

Note: The opt-in link only shows when an app is “Published.” Apps in “Draft” or “Pending publication” won’t show the opt-in link.

After clicking the opt-in link, your testers will get an explanation of what it means to be a tester and they’ll be able to opt-in.

Step 3: Get feedback

Once your alpha or beta testers have opted-in and installed your app using the link you provided, they’ll be automatically updated to the test version.

Because your testers can’t leave public reviews for alpha/beta apps on Google Play, it’s a good idea to let them know where they can provide you with feedback (an email address, website, etc.).

Alpha/Beta availability

Alpha and beta APKs need to have a higher version code than production APKs to be available for testing.

• To be available for alpha testers, alpha APKs need to have a higher version code than beta APKs.
• If a beta APK is uploaded with a higher version code than an alpha APK, the alpha version will automatically be deactivated.
• If a Production APK is uploaded with a higher version code than an alpha or beta APK, the alpha and/or beta version will automatically be deactivated.

Alpha testing group users are eligible for the alpha, beta, or production version of your app with the highest version code that is compatible with their device. Beta testing group users are only eligible for the beta or production version of your app with the highest version code that is compatible with their device.

Q&A

1.What is exactly the difference between them, especially between Alpha and Beta?

There isn’t much difference between the two aside from the fact that you just start with a small number of testers for alpha testing and switch to a bigger group for beta

2.Only the production stage is available for people on the play store, right?

Yes, that is correct.

3.which one/s allow to publish only to specific people/percentage , and in which way do you do it?

You can do that for both. To do alpha,beta testing you need to send invites to people on their google+ accounts so that they can access your app and be able to download it. The invites is usually in the form of a link directing them to your app on the play store which is only visible to them after they accept the invite

4.which stage allows in-app billing, at least for testing ? I don’t get why can’t i test it out even before uploading the app.

You can do in-app billing for both alpha,beta testing. Check the link:http://developer.android.com/google/play/billing/billing_testing.html

5.in the percentage method, if I publish a new app version using the same way, will it first update for the people who were lucky enough to install the previous version?

As far as my experience goes, i have seen people who were testers get the update for the app first than everyone else. But i am not so sure about how does it work exactly.

References:

• https://developer.android.com/distribute/googleplay/developer-console.html
• https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
• http://stackoverflow.com/questions/20984120/need-some-clarification-about-beta-alpha-testing-on-the-developer-console