We'll continue where we left in Introduction to concepts and tools. The goal of this article is to set up a Jenkins server locally through automated and repeatable process with all the artifacts stored in the GIT repository. This will require tools like VirtualBox and Vagrant. It will also require registration to Docker. Unlike the previous article that provided only general information, in this one we'll have to get our hands dirty and follow the examples.
What do we need in order to have a Jenkins server up and running locally? We need a virtual machine or available server, operating system installed and configured, Jenkins installed and configured. Since everything we do needs to be reliable and repeatable, we'll also need a Version Control System. Examples in this article will use GitHub as VCS. Continue reading →
This is the first article of the Continuous Integration, Delivery and Deployment series. We'll start out journey with brief explanation of Continuous Delivery. After short exploration of some of the tools used today, we'll move towards the flow (from setting up brand new environment and getting the code from the repository to the creation of fully tested and verified distribution). Each section will present different approaches, compare different tools and, finally, provide some hand-on examples. After the flow, we'll explore changes required in the development life cycle. Finally, we'll dive into last steps required for the transition from Continuous Integration towards Continuous Delivery and Deployment.
You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.
There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).
Some kind of a project management tool or a task tracker
Version Control System (VCS)
Continuous Integration (CI) framework with jobs for each phase from the build to deployment
I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development. Continue reading →
To programmers, benefits of source control are obvious. Revision history, revert and recovery, team work, build and continuous integration tools integration, and so on and so forth. No one is questioning usage of source countrol any more. It all boils down to a simple rule: if it is not in source control, it does not exist. Build and continuous integration tools expect it to be in source control. If it is not there, it will not be built. If it was not built, it will not be deployed. If it was not deployed, it will not be tested. If it was not tested, it will not be put to production.