Code collaboration with Codefresh
In this tutorial we will see how Codefresh can be used by many developers who work on multiple features and how to create separate demo environments for each feature. You will learn how to:
- launch On-Demand test environments for Docker containers
- use pull requests for feature based development
- make sure that Codefresh builds automatically whenever a commit happens
Using Pull Requests for feature development is one of the tenets of a sound Continuous Integration process. Codefresh can be instructed to build pull requests in an automatic manner (or any other source code branch) making collaboration among teams much more flexible.
Codefresh also has the unique capability of launching Docker images in temporary test environments. These test environments are ephemeral and are not intended to be used as QA (let alone production) environments. They are perfect for quick demos. Use them if you want to quickly share a feature with a colleague or a customer.
Launching a Docker image using Codefresh
Docker images play a central role in Codefresh. The basic CI tutorial describes how you can easily create a Docker image from your source code.
In this section we will take this one step further and actually launch the result Docker image. Codefresh has the unique capability of launching a docker image (using Docker Swarm behind the scenes) on the same hosted environment that Codefresh itself runs.
This means that with zero effort from your side you can quickly inspect the status of your application using the Codefresh infrastructure.
As a first step you need to tell Codefresh what is the port exposed by your application. Codefresh needs this information in order to launch the Docker image and allow you to access it via your web browser.
The launch settings are at the same screen as the build settings. Find your project in the Codefresh dashboard and click on the small gear icon:
Selecting the exposed port
This time we will select the tab Launch settings:
The sample application we are using here is exposing its web interface at port 5000. We therefore set this value in the respective option. Now Codefresh knows which port should be exposed in the test environment (i.e. which port of the Docker container should be made available for external connections).
To start a Docker image as a demo environment, locate it in the Images section and click the launch button.
Our sample application is self-contained (it consists of only a single Docker image) so choose standalone for the popup menu. Codefresh can also launch demo environments for applications that consist of multiple images (e.g. a service image and a database image). This capability happens with Codefresh compositions which are described in detail in section On-Demand Environments.
Once your application is launched, Codefresh will present the run log. You will see the same messages that would appear if you executed the
docker run command locally.
Accessing the test environment
Once launch is complete, Codefresh will print a dynamic URL that contains the deployed environment. Now you have a demo environment created just for you! You can send this link with an email to a colleague to ask for feedback or to a customer to show progress.
The number of concurrent test environments that you can have depends on your Codefresh account. Remember that you should never treat these on demand environments as production ones. They were never designed that way.
If the environment is not functioning correctly for your own application make sure that the port exposed by Codefresh in the Launch settings is the one that is actually used in your application as an HTTP endpoint.
To find your existing on-demand environments, click Docker Swarm
-> Environments on the left part of the screen. You will get a list of your active environments. You can see details such as
- Which branch is this environment from
- Which Git commit represents this environment
- What is the URL endpoint created by Codefresh
On the right side, you can find a list of buttons that allow you to visit the environment directly, share the link on Slack and most importantly stop the environment, so that it doesn’t count against your account. It is a good practice to launch environments only when you need them and clean them up once you are done with them.
Collaborating with Pull requests
Continuous Integration (CI) is based on two pillar stones:
- The merging of all features into a shared mainline (this is the integration part)
- The capability to auto-build all commits and have a deployable artifact at any given point in time (this is the continuous part)
Your Git provider (e.g. Github) is the one responsible for the Integration part. Codefresh takes care of the Continuous part in a very natural way. It uses webhooks to respond to changes that happen in source control (either in the form of new commits or when branches are created)
Auto-build of branches and pull requests
By default Codefresh will connect to your Git provider and do the following:
- Auto-build every new commit that happens in master or any other branch
- Auto-build every new branch when it is created
You can change the default behavior so that it matches your own workflow using extra GIT Triggers.
You don’t have to anything special to setup this communication between Codefresh and your Git provider. It was setup automatically for you when you connected your Codefresh account to your Git provider.
Codefresh also creates for you a default GIT trigger the first time you create a project.
If you create a new branch in your repository Codefresh will automatically build it (and also store the resulting Docker image). The build will clearly define its source branch:
All branches are shown under the respective tab. You can build any branch on its own and you can also start a demo environment for any branch as well.
Codefresh also has a dedicated view for Pull Requests. When you open a Pull Request, Codefresh will show it under the respective tab. All facilities we described so far for the main branch are available for Pull requests as well. You can create demo environments for Pull Requests in the same manner. Previewing the changes of a specific feature has never been easier.
When you commit to a Pull Request, not only Codefresh will auto-build it, but you will also see the build request in the Github UI as well:
Different build options for branches and pull requests
So far we have used the same build options for all branches and pull requests. Codefresh allows you to define more than one groups of settings. The build settings can then be individually fine tuned with regards to:
- the build steps (e.g. unit tests and/or integration tests)
- the branch names they affect
- whether they run automatically or manually
With these basic building blocks it is possible to create any development process that matches your organization. Here are two extreme examples.
Early Start-up company:
- Main pipeline that runs automatically and deploys to production from master branch
- Testing pipeline that runs automatically and runs unit tests whenever a Pull request is opened
Fortune 500 company with complex approval process:
- Main pipeline that runs manually from master and executes both unit and integration tests. Deploys to production
- Testing pipeline that runs manually for staging and runs integration tests. Deploys to staging environment
- Code review pipeline that runs automatically from branches named feature-x and runs code quality and static analysis tools