What is a deploy?

Question

Each module of the project has a .war and a .war exploded, What are the functions of this artifacts in this "deploy" process? And what is Jenkins' function in that context? I understand that deploy is a process of "mount that War" because every time something is wrong I get one Build failed in Jenkins.

Answer 1

Broadly speaking, deploy means get into position.

In practice, we usually talk about providing a system for use, whether in a development environment, for testing or in production.

Term overload

A term deploy can mean many things, depending on the environment and technology. A developer can do the deploy of the web application in your local Tomcat. You can also do the deploy production Weblogic, used by real users.

Level of automation

The deploy can be "manual", partially automated or fully automated.

A process manual may consist of exporting a WAR in Eclipse, accessing the Tomcat Administration page and uploading WAR.

An automated process may consist of committing the code in the repository, and this action automatically triggers the build process (build) of the application’s "executable" and possibly its availability on a server.

Personalization

While the lifecycle of an application may be 100% automated, it does not mean that a commit Any of it will end in production. The important thing is that all the most laborious steps are automated, available to a developer or responsible command.

Developers and administrators should configure this entire environment in the way that is best suited to the project, minimizing rework, repetitive tasks, and human error throughout an application’s life cycle, ranging from specification to end-user acceptance.

For example, it doesn’t always make sense for a commited code to generate a production version of the system. Then several criteria can be adopted so that new implemented functionalities are properly delivered to the end user. The main strategy here is the correct use of branches (branches) developmental.

Continuous Integration (IC - Continuous Integration)

All this automation is not just about avoiding repetitive work. It actually allows developers to achieve a much higher level of productivity and quality.

A recurring problem in software development is that the hidden errors in the programs we develop are increasingly expensive and difficult to correct in measured time.

Anyone who works with programming must have already gone through the situation of thinking that a program was almost ready and "just needed to test", to find that, in fact, a lot was still wrong or even missing in the code.

Another recurring situation is the "laziness" of testing the software, or at least the practice of postponing the tests. No testing and deploy automated, the developer tends to write a lot of code before actually putting the program to run, after all if the process is laborious and takes a lot of time, he will avoid doing it to the maximum. Only that in the end it takes a lot of time to correct all the "details" that were not correct.

To mitigate all these problems, the concept of Continuous Integration emerged. The idea is precisely to automate the process so that quite often, once or more times a day, it is possible to integrate all the changes of all the developers involved in the project and carry out a general test.

Life cycle automation of an application

Continuous Integration is not always a simple task and there are many ways to do this.

Building (Build)

The build is the process that turns your source code into an "executable", such as a Jar or War in Java. Of course you can use a script of your own running the javac, but there are more advanced tools like Ant or Maven.

One of the most common methods of doing this in Java is using a tool like Maven. Maven manages the construction (build) projects through the use of conventions and standards. For example, projects that use Maven generally follow the following directory structure:

Basically, you put the application’s source code into src/main/java and automated testing in src/test/java.

Maven also defines a series of phases of project construction. See image below:

Let’s look at the main phases:

• Compile: compiles directory code src/*/java.
• Test: runs the tests found in the directory src/test/java
• Package: packs classes and other files into a JAR or WAR, for example.

There is also a phase of deploy which can be configured to make available the "executable" generated on a server. However, each server type needs a different plugin than Maven.

Finally, following the defined standards, which can also be customized, Maven allows to automate the whole process of build or construction of the project. There is also a phase

If you want to know more about Maven, I suggest reading the article:

Installing, configuring and using Maven to manage your dependencies and your Java projects

Managing at a high level

Building the project is the most important step, but Continuous Integration needs to take into account the entire company environment. After all, the developer cannot or should not always have direct access to do the deploy of your local machine.

In such cases, a company’s development environment can divide work between several servers containing specialized services. Here come applications like Jenkins to "put order in the mess".

Consider the illustration below:

In summary, the illustrated steps are:

1. Check in: is when the developer commit or merge of the code in branch configured for releases of the design in the versioning system (VCS - Version Control System). To branch is usually called HEAD in CVS, Trunk in the SVN and master in Git, but can be any other arbitrarily defined.

2. Changing your VCS then triggers a process on your Continuous Integration Server (CI Server), which may be Jenkins himself. The server will fire the build of the project on the build (build Servers).

3. If the project uses Maven, for example, the build server will then compile, test and package the project using this tool. First it recovers the source code (check out) from VCS and then, for example, run the command mvn package.

4. After the end of the build the CI Server (our Jenkins) retrieves the report from the compilation and the tests and checks if everything went well.

5. The CI Server then updates the project status.

6. The CI Server, in accordance with the configuration, notify the parties concerned of the outcome of the proceedings.

Within the above process, optionally, there could be a step to do the deploy of the application on a server. A way would be through the build Maven. Another would be to configure Jenkins to run the deploy after the build (step #4).

However, I find the approach of promote determined builds successfully completed manually. The process would still be all automated, but in the end the responsible for the project can select a certain build which has just come out of development and with one click, promote it for the testing environment or even for production.

Answer 2

Deploy means implanting. For example, after you have generated your program and want to put it on the air on your application server, what you are doing is deploying it on the server. Implanting means putting into the air, and the term for this in English is deploy. It is also important not to confuse implant with implement, are very different things and I have seen many people making confusion between these two terms.

Jenkins is just the program that automates the construction process. It invokes the compiler, executes the tests, runs the javadoc and executes whatever the process to make the deployment and also stores the history of each process of construction of your program as well as the generated artifacts. This error only says that the build process (usually compilation) failed and that whoever was running this process was Jenkins.

WAR is the "thing" that is actually deployed on a web server. It is nothing more than a JAR file with some special settings. However, within this WAR there may be other nested JAR files. In order for everything to run on the server, it needs to be blown up - that is, all the contents of the nested Jars must be extracted into WAR, nesting away and resulting in a flatterer hierarchy consisting only of WAR containing the classes of its application (including those in the Jars), then eliminating the nested Jars.

Finally, to deploy your application, Jenkins will do at least the following: Compile it, generate a WAR from it (perhaps blown up, depending on how it is configured) and then deploy it to your application server (which in your case is Tomcat).