browsers: ["ChromeHeadless"]

"karma-phantomjs-launcher": "1.0.4",
"phantomjs-prebuilt": "^2.1.16",

require("karma-phantomjs-launcher")

"capabilities: {
    'browserName': 'chrome',
    chromeOptions: {
      args: [ "--headless", "--disable-gpu", "--window-size=800x600" ]
    }
  },

npm install --save-dev puppeteer

process.env.CHROME_BIN = require('puppeteer').executablePath()

Building the Docker Image

# Stage 0, based on Node.js, to build and compile Angular
FROM node:8 as node
# See https://crbug.com/795759
RUN apt-get update && apt-get install -yq libgconf-2-4

# Install latest chrome dev package and fonts to support major 
# charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
# Note: this installs the necessary libs to make the bundled version 
# of Chromium that Puppeteer
# installs, work.
RUN apt-get update && apt-get install -y wget --no-install-recommends \
    && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
    && apt-get update \
    && apt-get install -y google-chrome-unstable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont \
      --no-install-recommends \
    && rm -rf /var/lib/apt/lists/* \
    && apt-get purge --auto-remove -y curl \
    && rm -rf /src/*.deb

# # It's a good idea to use dumb-init to help prevent zombie chrome processes.
# ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64 /usr/local/bin/dumb-init
# RUN chmod +x /usr/local/bin/dumb-init

# Uncomment to skip the chromium download when installing puppeteer. 
# If you do, you'll need to launch puppeteer with:
#     browser.launch({executablePath: 'google-chrome-unstable'})
# ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD true

WORKDIR /app
COPY package.json /app/
RUN npm install
COPY ./ /app/
# Run unit tests to ensure that the image being built is valid
RUN npm run test
# Run end to end tests to ensure that the image being built is valid
RUN npm run e2e
# Build the angular application with production configuration by default
ARG conf=production
RUN npm run build -- --configuration $conf

# Stage 1, based on Nginx, to have only the compiled app, ready for production with Nginx
FROM nginx:alpine
COPY --from=node /app/dist/ /usr/share/nginx/html
COPY ./nginx-custom.conf /etc/nginx/conf.d/default.conf

Building a CI/CD Pipeline on VSTS

Native Web Based Solutions (aka Compiled Applications)

Summary

1. Sign into your Azure Account at https://portal.azure.com.
2. In the Azure Portal, choose New, Containers, then choose Azure Container Registry.
3. Enter a Registry name, Resource Group, and select a Location.
4. For Admin user, choose Enable and then choose Create.
5. Wait for the Azure Container Registry deployment to finish.

1. 1. In the Build & Release hub, open the build summary for your build.
   2. In the build summary page, choose the Release icon to start a new release definition.
   3. Select the Azure App Service Deployment task and choose Apply.
   4. Configure the properties as follows:

Building The Application

Creating the Azure Web App

1. New -> Web and Mobile -> Web App
2. Fill out the required fields: 
3. After pressing "Create" you should now have an Azure Web App created.

Setting Up CI Pipeline With VSTS

1. Build and Release -> Builds -> New
2. Add an npm task to install the npm packages required by the Angular application
3. Add another npm task to build the application and create the dist folder:
4. Add a publish artifact task that generates the dist artifact which will be provided later on as an input to our release definition:

Setting Up CD Pipeline With VSTS

• Myth 2: Visual Studio is a better choice for back-end piece whereas VS Code would be a better choice for the front-end piece.
• Reality: Both are equipped to handle both scenarios. With the new Asp.Net CLI tools for example you can now easily build Asp.Net WebApi projects with VS Code as the tools are disconnected from the IDE.

• Myth3: Use VS Code only if you are working against git based repositories as VS Code doesn't support checking into repositories using TFVC as the version control.
• Reality: Both support Git and TFVC.

1. Create a web application that supports responsive design.
2. Go native and hence target each platform with its own set of SDKS, IDEs, languages, etc.
3. Go with a cross-platform approach and ‘hopefully’ achieve significant cost savings in terms of code sharing, maintenance optimization, and development team optimization.

1. Makes it challenging to access native device capabilities.
2. No app store presence and hence it makes it harder to distribute and monetize.

1. Hybrid approach.
2. Native approach (not to be confused with native approach mentioned above).

1. Skillset of the team responsible for building the application. If your team is more comfortable using web technologies then Apache Cordova may be a better option.
2. Time to Market. There is some upfront investment required with Xamarin as some understanding of the different platforms is required.
3. Shared or Platform specific UI. Xamarin provides a rich suite of UI controls that map one to one with the native counterparts. With Apache Cordova you have to take the responsibility of building these controls yourself (it always helps to check if the OS community may have already implemented it).