This article is for versions of Angular 2, Angular 4, Angular 5 and later.

In this post we are going to cover how to get a Angular application up and running and then deploy it to Firebase. First lets cover how to use the Angular CLI to help bootstrap our application’s build process.

Angular CLI

The Angular CLI is an officially supported project by the Angular team. You can find more information at https://cli.angular.io. First we will install the Angular CLI tool. To install we install via NPM running the following command: npm install angular-cli -g. This will install the CLI globally to our machine to help us create new Angular projects.

Once installed we can create a new Angular app by running the following command: ng new my-cool-app. Next open your app in your favorite editor and you should see something similar to this (as of CLI beta 10):

New Angular CLI project Structure

Starting the CLI

Now running a command prompt at the root of our project we can run the following command: ng serve. This will build our project and start a live reload server for development. So if we browse to localhost:4200 we should see the following:

Running Angular CLI app

Build for Production

I won't cover all the CLI commands in this post. I recommend checking out the CLI Docs. We will just start with running ng build --prod. This command runs a build for our project but with additional production optimizations such as bundling and minification. Now your project should have a dist/ directory. This is where all of our compiled ready to deploy code is located every time we run a build.

Firebase CLI

So now that we have learned how to use the Angular CLI to package up our app for deployment we will use the Firebase CLI to create a live hosting project to deploy to.

First you will want to log into Firebase and go to https://console.firebase.google.com/. Once in the console select “Create New Project”. For our project we will name it “my-cool-app”.

Creating a Firebase Project

Now that we have a project created lets go back to the command line. Next we next install the Firebase CLI via NPM. In your console run the following command: npm install -g firebase-tools. Once installed run firebase login to login to your Firebase account.

Deployment Setup

Now that Firebase CLI is installed, at the root of your Angular CLI project run firebase init. This will walk through the steps of setting up your app to be deployable to Firebase Hosting.

Creating a Firebase Hosting Project

Select the Hosting option in the command line. Next select our project my-cool-app that we created earlier. Next it will ask what file to use for the Firebase real time database rules. For now you can just use the default.

The next step is important! The cli will ask what folder to use as the public directory. For our project we want to use the dist/ directory instead of Firebase’s default public/ directory. So type in the command line dist.

Next it will ask if this is a single page app and if it should rewrite all urls to index.html. For our app select yes. If it asks to over write the index.html file select no. Now your app is ready for deployment! In the root of your app you should have a new file firebase.json file that helps the Firebase CLI know how to deploy our application. Now run firebase deploy. Firebase will provide domain that you can configure to a custom domain in the console. Now if we open our browser we will see something similar to the following:

Live Angular Firebase project

Now that we have created an Angular project and deployed it to Firebase I recommend digging into more of the Angular CLI and the Firebase Features. A few things to note, the CLI at the time of this writing is in Beta 10. A large change is in the works for Beta 11 to switch the underlying build system to Webpack. This post will be updated with those changes. Also in future versions of the Angular CLI will possibly have Firebase integration and deployment built in. Also as of Beta 10 of the Angular CLI production build do not have a versioning system to bust browser cache. This should be addressed in upcoming versions.

5 KEY SOFTWARE TESTING STEPS EVERY ENGINEER SHOULD PERFORM

In recent years, the term "shift-left testing" has entered the software engineering vernacular. But what does that mean? In plain English, it means conducting more software testing during the software development phase.

Shift-left testing is often used to describe increased involvement by quality assurance (QA) engineers during the development phase in an effort to detect defects as early as possible, before software engineers have handed the program over to QA for more extensive testing. Most of the time, it means developing and executing more automated testing of the UI and APIs.

However, there are some basic and essential software testing steps every software developer should perform before showing someone else their work, whether it's for shift-left testing, formal testing, ad hoc testing, code merging and integration, or just calling a colleague over to take a quick look. The goal of this basic testing is to detect the obvious bugs that jump out immediately. Otherwise, you get into an expensive and unnecessary cycle of having to describe the problem to the developer, who then has to reproduce it, debug it, and solve it, before trying again.

Here are the essential software testing steps every software engineer should perform before showing their work to someone else.

1. Basic functionality testing

Begin by making sure that every button on every screen works. You also need to ensure that you can enter simple text into each field without crashing the software. You don't have to try out all the different combinations of clicks and characters, or edge conditions, because that's what your testers do—and they're really good at that. The goal here is this: don't let other people touch your work if it's going to crash as soon as they enter their own name into the username field. If the feature is designed to be accessed by way of an API, you need to run tests to make sure that the basic API functionality works before submitting it for more intensive testing. If your basic functionality testing detects something that doesn't work, that's fine. Just tell them that it doesn't work, that you're aware of it, and that they shouldn't bother trying it. You can fix it later, just don't leave any surprises in there.

2. Code review

Another pair of eyes looking at the source code can uncover a lot of problems. If your coding methodology requires peer review, perform this step before you hand the code over for testing. Remember to do your basic functionality testing before the code review, though.

3. Static code analysis

There are tools that can perform analysis on source code or bytecode without executing it. These static code analysis tools can look for many weaknesses in the source code, such as security vulnerabilities and potential concurrency issues. Use static code analysis tools to enforce coding standards, and configure those tools to run automatically as part of the build.

4. Unit testing

Developers will write unit tests to make sure that the unit (be it a method, class, or component) is working as expected and test across a range of valid and invalid inputs. In a continuous integration environment, unit tests should run every time you commit a change to the source code repository, and you should run them on your development machine as well. Some teams have coverage goals for their unit tests and will fail a build if the unit tests aren't extensive enough.

Developers also work with mock objects and virtualized services to make sure their units can be tested independently. If your unit tests fail, fix them before letting someone else use your code. If for any reason you can't fix them right now, let the other person know what has failed, so it won't come as a surprise when they come across the problem.

5. Single-user performance testing

Some teams have load and performance testing baked into their continuous integration process and run load tests as soon as code is checked in. This is particularly true for back-end code. But developers should also be looking at single-user performance on the front end and making sure the software is responsive when only they are using the system. If it's taking more than a few seconds to display a web page taken from a local or emulated (and therefore responsive) web server, find out what client-side code is slowing things down and fix it before you let someone else see it.