Front-end Automation development workflow

1. Introduction to front-end automation workflows

Each project has its own specific development process and workflow. From the requirements analysis, design, coding, testing, publishing, a whole development process, according to different circumstances to form their own unique steps and processes. The process of a workflow is not fixed in the first place, but is continuously improved as the project progresses, and even some tools are formed during the period. For example, when the great gods in Linux write C language, think every time to compile a lot of files good trouble, invented the makefile. The management of different code is troublesome, then invented git, svn and so on.

The quality of a workflow will affect the efficiency of your development, the level of development process, and then indirectly affect the mood, to combat coding enthusiasm. So I think it's a very important step to develop a project by clearly identifying the workflow before coding it. And the process needs to be constantly improved in the real world.

A good workflow is critical for the front end that is responsible for page structure and content, appearance, and logic. And there's no silver bullets in here. To adapt a unique workflow based on the framework and application scenario used for the specific project.

I'll introduce a front-end workflow that I often use, a workflow that is just a raw process, and in general, I'll tweak it based on different projects to create a unique process for each project. So the point here is to understand the idea of building a workflow and then learn to extrapolate.

A front-end automation development process, I think at least the following points need to be done:

1. Good modularity
2. Automated compilation
3. Automated testing
4. Refresh the page in real time
5. Automated packaging, compressed publishing

The machine can be used in the place do not do their own, in addition to the above necessary points, sometimes to the specific circumstances to write some python, Nodejs, shell scripts to avoid duplication of operations. Take good care of your F5 and sparse cranial nerves, men should be better to themselves.

2. Reserve knowledge

Before the formal introduction, we will do some knowledge of the reserve, and will skip some of the knowledge you may not understand. Understand the words can be skipped, met do not understand can Google, do not Baidu.

2.1 Engineering Catalogue

My project catalogue is usually this kind of:

├─assets/│  └─images/├─bin/├─dist/├─lib/├─src/│  ├─coffee/│  │  └─main.coffee│  └─less/│     └─main.less├─test/│   └─specs/├─node_modules/├─index.html├─Gruntfile.coffee├─package.json├─.gitignore└─README.md

All subdirectory names are actually derived from the ancient C-language project.

Assets: General storage is the picture, audio, video, font and other code-independent static resources, I generally only picture, and sometimes create a new fonts folder or something.

bin: binary abbreviation, this name comes from our ancient C language project, because the general C language to compile into executable binary files or something, and then basically become a default label. So the front-end compiled files will also be stored in the bin/directory.

Dist: Distribution's abbreviation, the file in the compiled bin is not used directly for publishing, but it passes through a series of optimizations, such as packaging compression. Files that can eventually be deployed to the release environment are stored in dist, so the dist inside is code that can be used directly into the production environment.

Lib: the library's abbreviation for storing a third-party repository file. such as jquery, Fastclick or something you like. But then you will see that in our modular approach, this folder is generally more of a chicken's existence.

src: The abbreviation of source, the place where all the source code that needs to be developed is the folder that we generally operate most. Simply divided into coffee, less two folders, the existence of logic code and style (I generally use coffeescript and lesscss, of course you can also change to your favorite language, Js,ts,ls,sass, the idea is the same). You see two folders under the Main.coffe, Main.less, which is actually the logical code and style code of the main entry file, will be introduced to other modules and styles, through a mechanism to synthesize a file. It will be explained in detail next.

In addition, the way the directory is organized will vary according to the actual situation. Sometimes you will need an HTML template, possibly one more tpl/directory. Perhaps your directory is not this type-based hierarchical organization, but is based on the page parts of the organization, the components/directory may appear, and then there are many pages parts of the directory, each subdirectory has its own coffee, less, HTML. (This form has become increasingly popular.) Because of the file type directory, when the project is complex, it becomes extremely difficult to maintain, based on the components will be quite convenient.

test: Programming with testing-driven (TDD) development, where the test sample is stored.

index.html: Paging file

The next few files are not explained, do not know can preview Nodejs, Git, grunt this several things.

2.2 modularity

Talking about front-end modularity is also a lengthy topic. There are many ways of front-end modularity, and young people like to use the Requirejs, Seajs, and so on, when they see these modular tools and feel as excited as their first pair of skateboard shoes. In fact, this AMD, CMD need to introduce a library file to do modular tools, and complex configuration, a variety of asynchronous loading problems. Later I found that the most clean, direct, convenient, powerful modular way is the substack of the great God. Browserify.

It can be based on the Nodejs platform to implement modular tools, you can organize your own front-end project as the organization Nodejs code, all the modules can directly require in like Nodejs. Provide a portal file (such as Main.coffee above) to Browserify, which will package all dependent modules of the portal file into a single file. The final file is not dependent on browserify, and the final file is a combination of your logic code.

and browserify and Nodejs module compatibility is very good, some nodejs with the module such as util, path can be used in the front end. You use NPM to install the library, you can also use Browserify to the front-end! For example I want to use jquery, I just need: npm install jquery --save . Then in the Main.coffee:

require "jquery"// play with jquery

Quite intimate.

(Browserify specific Usage view official documents)

2.3 Process automation Tools

In fact, there are many ways to automate, you can:

• Configure the script for NPM to automate task management directly with NPM.
• Use the old makefile and shell scripts
• Grunt
• Gulp

The first two methods are more suitable for the Nodejs development service side of the application scenario, the front end is generally more suitable for the latter two.

Currently used is grunt, choose it is because it community large, multi-plug, mature. But I'm more optimistic about the gulp based on stream, this unparalleled implementation of Unix-like thinking can really make it a difference in performance and grunt. Grunt based file implementation is in: too! Slow! The!

(Grunt specific usage can be found in the official website document)

2.4 Testing

Testing is another big topic. In foreign countries, the front-end TDD, BDD development has been quite mature, a variety of cool tools jasmine, Mocha, tape and so on, may be I compare ignorant, seemingly rarely seen in the domestic use of these tools.

In fact, the front-end is very difficult to complete test-driven development, which itself involves many subjective factors, such as animation is not as expected to move and so on. But logic code and front-end Interface logic can be tested. So the introduction of test-driven development of a very big advantage is: As long as the interface is determined, the front and rear end can be separated development, the frontend no longer "wait for the backend API implementation."

In our workflow, using MOCHAJS as the test suite, Chaijs as the assertion library, sinon as the data mocking and function spy. Specific usage can be seen on their respective websites.

(For the front-end test driver development does not understand the students can Google related Materials or access to related books)

3. Automating Workflow 3.1 Templates

The template for this workflow has been stored on GitHub and you can clone it for local testing: https://github.com/livoras/feb.git

To run the steps:

1. The computer must first press the NODEJS and NPM installed.

2. Install Browswerify,coffeescript, and grunt:

   NPM Install browswerify coffee-script grunt-cli-g

3. Fork the warehouse to local, enter the engineering directory, install dependencies:

   NPM Install

4. Then run the grunt command

With luck you can see this interface:

Then you'll find a bin folder in the project directory, and that's where the files we just compiled are stored in the bin.

Then open the browser and go to http://localhost:3000, you can see:

Now we modify the Src/less/main.less file and change the body to black to see:

Then go back to the browser to see:

Quicker, very oh Sister (amazing) is not?

The workflow is divided into two simple steps:

1. Development time
2. When distributed

Now let me introduce you.

3.2 Development Time

Let's take a look at Gruntfile's 100~108 line:

In fact, Grunt did such a few things:

1. turn on the local server for debugging : Using a Connect plugin from grunt, a local server is opened, localhost:3000, and the project directory is the root directory.
2. Delete the original compiled file that was previously obsolete : Delete the entire bin folder
3. compile coffeescript and use Browserify for dependency merging : src/coffee/The following main.coffee as the portal, compiles all the dependent modules into JS and merges them into a file, which is stored in the bin/js/directory. Open bin/js/You can see there is a main.js below. Careful but words, you will find, in fact, Main.coffee is dependent on the same directory of a module called Another-module.coffee. At compile time, Browserify will parse the entire Main.coffee dependency tree and find all dependencies to merge, so the bin/js/main.js you see is actually the content of two modules. So we can write the module in Nodejs Way, the front-end only need to merge the good file.
4. compileLess: Compile src/less/main.less into the bin/css/directory, and less can also refer to the module (through) in a manner similar to coffee import . So our style is also a modular of Meng Meng.
5. Run tests : All tests are stored under Test/specs, and after compiling, grunt runs the Moch run test sample. You can see in the window that we have a total of three Tests running and passed.
6. Monitor file changes, once the file changes, re-execute the steps. and automatically refreshes the browser : With the grunt Watch plugin, we can do this once the file is modified, recompile the coffeescript,less, run the test, and refresh the browser automatically.

With such a process, you can easily write the logic and style of the front end, all in a modular way.

3.3 at release

All right, the code is finished. I need to deploy my code on the server. Very simple, just need to execute on the command line:

grunt build

You will find a Dist folder in the project directory, enter the inside, you can see:

Open index.html directly:

It can be opened directly, is very oh sister is not?

Let's look at the build task of grunt:

Grunt build did a few things:

1. Delete the previously compiled file, as above.
2. Delete the previously published file, i.e. delete the entire dist directory.
3. Compile coffee and less, ibid.
4. Test, before publishing or need to see if there is a problem.
5. Uglify, the bin/js/main.js to confuse compression, put under dist/js/.
6. Cssmin, the bin/css/main.css to confuse compression, put under DIST/CSS.
7. Copy the assets directory to Dist
8. Copy the index.html, do some processing (change the relative path, etc.) and store it under dist/

You can see the files in the Dist directory JS and CSS files are compressed, and now Dist folder is ready, you can always be placed directly on the server.

4. Finally

The above is actually a very simple process, in the actual process is more complex than this, for example, to consider building directory automation, version management automation, deployment automation, image merging optimization and so on. There is this awareness: * Do not do any repetitive work, can be automated to the place can be the idea of trying to automate *.

It also skips a lot of basics, which you need to know:

1. Use of Grunt
2. Basic use of Nodejs
3. Modular concept
4. The concept of TDD testing and the use of basic test suites
5. Coffee,less,browserify but use etc.

I even skipped the process of building the whole process, and I skipped how the test was written. In fact, many of the details can be expanded to say, testing, modularity, and so on, the next blog may be in this direction to write.

Front-end Automation development workflow