DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives.
Source: Wikipedia
In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.
Source: Wikipedia
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.
Source: Wikipedia
The developers are storing their code in "Git". Git, originally created by Linus Thorvalds who also created the Linux kernel, is more a protocol than a tool. Often, an implementation of this protocol is used on a server tool like GitLab, whereas the tool provides also the interface, user management and other items Linux left out.
Examples of "Git servers":
Tools to work with Git as a client:
It's very important to detect errors as fast as possible. Using Gradle with Groovy, you can easily run pre-build validation checks on the code. If a developer made an error or forgot something, he or she can immediately detect it running a simple command line like 'gradle validate'.
Also, as you can set dependencies between tasks in Gradle, you can set that each build must be proceded by a validation. The build will not start if the validation rules are not matched, saving valuable time.
Gradle is a modern build tool with an understandable syntax, which is close to the Groovy syntax as internally it's build on Groovy. By default, you can build the most common types of projects (Java applications, web applications, ...) by enabling the correct plugin.
However, you can extend Gradle with your own Groovy code which litteraly allows you to build whatever you want. And as Groovy can use Java libraries, you can include basically any Java library available in your Gradle builds.
With Gradle it's a piece of cake to add unit testing. With Gradle's approach of putting source code and testing code in dedicated directories, it's easy to run unit tests over and over again. The developer for example is immediately aware if he or she breaks code which was not even considered impacted.
When the build is finished, Gradle can easily run a validation on the artifact built. If the developer forgot something needed for deployment, it's detected straight away. Again, as you can code in Gradle, you can create your own post-validation with as many rules as you want.
Nexus is commonly used to store the artifact, the resulting binaries of the build. With Gradle's depencencies, the tool can easily download all the needed artifacts from Nexus and use them. Whereas Git is the place to store the code, Nexus is the place where you store your results.
You can easily use Gradle's plugins to deploy for example .war files on a Tomcat server. And if there's no plugin, some Groovy and you have your perfect deployment engine.
Another solution that Asynchrone can propose and work with, is IBM's Urban Code Deploy. This graphical tool allows deployments to be orchestrated over several servers in different environments. You can even have the business people formally accept a release and let them execute the deployment to production at their conveniance.
Sometimes, it's even better to create a Docker image containing your sources. Once the container is tested, you can install it as many times as you want with just a single command line.
Nothing fails as much as a human itself. How many times are things forgotten. Or simply not executed by lack of time. Introduce Jenkins, your server that runs all your tasks based upon a schedule over and over again. Jenkins never forgets, never gets bored and is available 24/7.