Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions _data/home-content.yml
Original file line number Diff line number Diff line change
@@ -1,5 +1,21 @@



- title: Getting started
icon: images/home-icons/started.svg
url: ''
links:
- title: Introduction to Codefresh
localurl: /docs/getting-started/intro-to-codefresh/
- title: Codefresh for CI
localurl: /docs/getting-started/ci-codefresh/
- title: Codefresh for CD
localurl: /docs/getting-started/cd-codefresh/
- title: Codefresh for GitOps
localurl: /docs/getting-started/gitops-codefresh/
- title: Concepts in Codefresh
localurl: /docs/getting-started/concepts/

- title: Dashboards & insights
icon: images/home-icons/guides.png
url: ''
Expand Down Expand Up @@ -41,6 +57,7 @@
localurl: /docs/ci-cd-guides/progressive-delivery/



- title: Example catalog
icon: images/home-icons/tutorial.svg
url: ''
Expand Down
17 changes: 17 additions & 0 deletions _data/nav.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,23 @@



- title: Getting started
url: "/getting-started"
pages:
- title: Introduction to Codefresh
url: "/intro-to-codefresh"
- title: Codefresh for CI
url: "/ci-codefresh"
- title: Codefresh for CD
url: "/cd-codefresh"
- title: Codefresh for GitOps
url: "/gitops-codefresh"
- title: Concepts in Codefresh
url: "/concepts"




- title: Dashboards & Insights
url: "/dashboards"
pages:
Expand Down
91 changes: 91 additions & 0 deletions _docs/getting-started/cd-codefresh.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
title: "Codefresh for CD"
description: "Continuous deployment (CD) with Codefresh pipelines"
group: getting-started
toc: true
---

Work in progress TBD

<!--Focus on

Connecting K8s cluster
Deploying K8s
Running kubectl
Connecting to Helm registries
Building Helm charts
Pushing Helm charts
Deploying Helm charts
Dashboards -->


## Connecting to Kubernetes
Continuous deployment starts with Kubernetes clusters, and Codefresh integrates with any known cluster provider for Kubernetes through a few simple steps. Connect your Google, Azure, Amazon Kubernetes cluster to Codefresh through simple integration steps.
For those Kubernetes clusters that are not in our list of cluster providers, you can manually enter your cluster settings to add any generic Kubernetes cluster.

See [Connecting a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster).

## Deploying to Kubernetes
Codefresh offers a variety of options for you to choose from when deploying to Kubernetes.
Deploy to Kubernetes from the Codefresh UI, or programmatically through dedicated steps in pipelines, avoiding the need for `kubectl` commands.

**On-demand deployment**
For quick and easy deployment, deploy on-demand from the Codefresh UI.

**Dedicated steps in pipelines**
We have the `deploy` step, and the more advanced `cf-deploy-kubernetes`step that enables simple templating on Kubernetes manifests.

Codefresh pipelines also support Kustomize and Helm for deployments through freestyle steps.

Finally, if you are familiar with and want to work with `kubectl`, run your own custom `kubectl` commands in a freestyle step. Read more in [kubectl](#kubectl).

See [Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/kubernetes/deployment-options-to-kubernetes/).

## kubectl
`kubectl` is the command line interface for managing kubernetes clusters. Running custom `kubectl` commands in a freestyle step gives your maximum flexibility with cluster deployments.
Codefresh automatically sets up your config context with your connected clusters. The config context is the value of the `$CF_KUBECONFIG_PATH` variable, which expands to `/codefresh/volume/sensitive/.kube/config` within the shared step volume.

Codefresh has a public Docker image for kubectl at [Docker Hub](https://hub.docker.com/r/codefresh/kubectl/tags){:target="\_blank"} that you can use.

Because Codefresh automatically sets up your `kubeconfig` files with the information from your cluster integrations, you can modify the current config context and run any `kubectl` command you want applied to that context. For example, leverage the parallel capability of Codefresh pipelines to create two Docker images and deploy them to two different clusters with custom `kubectl` commands.

See [Running custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/).

## Helm and Codefresh
Codefresh supplies a built-in Helm repository with every Codefresh account. And supports, besides public HTTP repositories, several private, authenticated Helm repositories.

**Connect to Helm repositories**
In addition to the official Helm repositories which are displayed in the Helm charts, Codefresh allows you connect with any external Helm repository through simple integrations. You can then inject the Helm repository context into your pipelines by selecting the repository name.

**Build Helm charts**
Install Helm charts from Helm repositories, or build a new one.

<!--Codefresh has a dedicated step for Helm step to easily integrate Helm in Codefresh pipelines, and authenticate, configure, and execute Helm commands.
The Helm step can operate in one of three modes covering most scenarios:
* Install the chart into a Kubernetes cluster. This is the default mode if not explicitly set.
* Package the chart and push it to the defined repository.
Authentication to set up authentication and add the repo to Helm. This is useful if you want to write your own helm commands using the freestyle step’s commands property, but you still want the step to handle authentication. -->

Deploy Helm charts
Deploy the Helm chart to a Kubernetes cluster, Helm repo, or both.


## Dashboards

TBD
<!--Dashboards are key to providing the right information at the right time.

Helm Boards


Helm Releases
The Helm Releases dashboard provides a unique view into your production Kubernetes cluster, and actions for . You can see the current status of your cluster, including the currently deployed releases, their previous revisions including change tracking, and even roll back to a previous release.

perational Dashboards ~ Exposing the most commonly needed application and environmental information to developers so that they can troubleshoot without needing assistance from the DevOps teams; even in production

Analytical Dashboards ~ Developers often need to reach out to the DevOps team to get statistics and metrics around builds and deployments. Codefresh automatically generates DORA metrics as well as many other key indicators of build and deployment efficiency, which can be easily viewed in seconds by product owners and management alike.

Kubernetes Services

Environments
-->
98 changes: 98 additions & 0 deletions _docs/getting-started/ci-codefresh.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
---
title: "Codefresh for CI"
description: "Continuous integration (CI) with Codefresh pipelines"
group: getting-started
toc: true
---

<!--Focus on:
Building Docker images
Compiling code
Running unit tests
Running integration tests
Security scans
Code quality -->

Work in progress


## Docker images
WBuilding a Docker image from the source code is probably the most common and basic requirement for a CI pipeline. In Codefresh you can build, push, and promote Docker images, using declarative YAML and credentials that are defined once stored centrally.

**Build and push image**
Building a Dockerfile in a pipeline works in the same way as building the Dockerfile locally on your workstation. The `build` step in Codefresh enables you to build a Docker image in a completely declarative manner, and to automatically push it to your default Docker registry without any configuration.

See:
[Build and push Docker images]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image/)


**View image**
The Images dashboard displays images from all registries connected to Codefresh. Every image is enriched with Git branch, Git hash and commit message, and any tags defined for the image.

See:
[Viewing Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)



**Promote image**
Promote an image by copying it from one registry to another. You can promote images either from the Codefresh UI, or automatically from pipelines by specifying an existing image in the pipeline step.

See:
[Promoting Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)


## Code compilation
TBD

## Unit testing
Codefresh supports all testing frameworks, including mocking frameworks, for all popular programming languages. Easily run unit tests on the source code of the application for every commit or pull request (PR) through our freestyle step in pipelines.

Run any type of unit tests in Codefresh pipelines, from smoke tests in a dockerfile, to tests with external or application images for simple applications, and evenrun them on a special testing image for complex applications.
You can create test reports and view them whenever you need.

See:
[Run unit tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-unit-tests/)


## Integration testing
Compared to unit tests that run on the source code, integration tests run on the application itself. You need to either launch the application itself, or one or more external services such as a database.
In Codefresh, you can launch these sidecar containers within the pipeline through compositions and service containers.


See:
[Run integration tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integrations-tests/)

## Security scanning
Security scans are critical to deploying quality code. With Codefresh, in addition you can control when to implement the security scan, and then view the scan results in the Codefresh UI, without having to go to the security platform.

**Security scan platforms**
Codefresh can integrate with any security scanning platform that scans source code or Docker images for vulnerabilities. We already have ready-to-use Docker images for several security platforms such as Anchore, Aqua Security, Clair, Twistlock and WhiteSource. For the full list, visit our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.

**Scan timing in pipeline step**
The security scan is implemented through a freestyle step, inserted anywhere in the pipeline. The fact that you can insert the step anywhere allows you to control when the scan is executed, for example, before the source code is packaged in a container, or before the container is stored in a registry or deployed to production, or any combination of these.

**View scan results**
As with any scan, the final step is viewing the scan results. Make the scan results available in Codefresh release dashboards (Test Report button) by attaching analysis reports to the pipeline build.

**Security annotations**
Correlate the Docker images in Codefresh with the results of the security scanning platform by adding annotations for custom metatdata. For example, you can add annotations such as the number of issues or the URL of the full report.

See:
[Security scanning tests]({{site.baseurl}}/docs/testing/security-scanning/)
[Test reporting modes]({{site.baseurl}}/docs/testing/test-reports/)
[Metadata in Docker images]({{site.baseurl}}/docs/pipelines//docker-image-metadata/)



## Code quality coverage
Good quality code is central to any CI platform or tool. Codefresh integrates with the top code quality platforms/tools in the market to track code coverage, inspect code quailty, and generate code-coverage analysis reports.

Three steps to
* Set up integrations with the platforms/tools (Coverall, SonarQube, Codecov, for example).
* Copy and paste the ready-to-use step for your platform/tool into your pipeline from our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.
* Reference them by name in the pipeline step, and view the updated reports in the respective UIs.

See:
[Code coverage examples]({{site.baseurl}}/docs/example-catalog/examples/#code-coverage-examples)


113 changes: 113 additions & 0 deletions _docs/getting-started/concepts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
---
title: "Concepts in Codefresh"
description: "Understand terminology and nuances in Codefresh"
group: getting-started
toc: true
---
Work in progress


### Runtime
A Runtime in Codefresh is a GitOps installation in your Codefresh account, in either a Hosted or Hybrid installation environment. Hosted Runtimes are installed on a Codefresh cluster and managed by Codefresh. Hybrid Runtimes are installed on customer clusters, and managed by the customers.
You can install a single Hosted runtime, and multiple Hybrid Runtines in a Codefresh account.


<!--add diagram -->
A single Runtime can connect to and manage multiple remote clusters.


See:
[GitOps runtime architecture]({{site.baseurl}}/docs/installation/runtime-architecture)
[Hybrid GitOps Runtime installation]({{site.baseurl}}/docs/installation/hybrid-gitops)
[Hosted GitOps Runtime installation]({{site.baseurl}}/docs/installation/hosted-runtime)



### Runner
The Runner is the hybrid installation option for CI/CD pipelines in your Codefresh account. The Runner is installed as a Kubernetes native application on any Kubernetes-compliant cluster. It allows you to run pipelines on your own Kubernetes cluster, including private clusters behind company firewalls.

Codefresh Runner gives you:
* Access to secure services (such as Git repositories or databases) that are behind the firewall and normally not accessible to the public cloud.
* The ability to use special resources in your Codefresh pipeline that are unique to your application, GPU nodes or other special hardware only present in your data center.
* Complete control over the build environment in addition to resources for pipelines.

Every Runner installation creates a runtime enviroment in your account. Assign the Runner to any pipeline to automatically run the pipeline in your own cluster. External integrations (such as Docker registry or Helm repositories) are also available to the Runner making pipelines exactly the same regardless of their runtime environment.

You can have multiple Runner installations in the same Codefresh account. A Runner can also manage multiple remote clusters in your account.

See:
[Codefresh Runner installation]({{site.baseurl}}/docs/installation/codefresh-runner)
[Runner installation behind firewalls]({{site.baseurl}}/docs/reference/behind-the-firewall)


### Project
A project is a top-level entity in Codefresh for grouping related pipelines. Projects can group pipelines according to any criteria that is relevant to your enterprise. The criteria can be logical and based on teams, departments, or location for example, or funtional, and based microservices in applications.
Projects centralize viewing and configuration settings for the pipelines that belong to them:
* Selecting a pipeline shows the other pipelines in the same project.
* Define access control and user-defined variables for the project, and they are inherited by all the pipelines assigned to the project

There are no limits to the number of projects you can create in your account. You can also create standalone pipelines and assign them later to a project, or detach a pipeline assigned to a project.

See:
[Projects in pipelines]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-concepts)

### Pipeline
The pipeline is the central component in Codefresh that implements CI/CD processes. Everything for CI/CD in Codefresh starts and ends with pipelines. a pipeline can do only CI, only CD, both CI and CD, or run any custom action, such as unit and integration tests.

A CI pipeline can compile and package code, build and push Docker images. A CD pipeline can deploy applications/artifacts to VMs, Kubernetes clusters, FTP sites, S3 buckets, and more. And a CI/CD pipeline can combine code compilation, integration, and deployment for full CI/CD.

More to be added...

<!-- ### Workflow
A workflow is type of Kubernetes resource that lets you define and run automated workflows, and stores their state.
Argo Workflows is an open source workflow engine that orchestrates parallel tasks on Kubernetes, implemented as a set of Kubernetes custom resource definitions (CRDs).

Argo Workflows is part of the Argo project, which provides Kubernetes-native software delivery tools including Argo CD, Argo Events and Argo Rollouts.

What are worklfows in Codefresh?
Workflows in Codefresh refers to our integration with Argo Workflows to implement continours integration topped with our unique functionlaity on top of vanilla

Triggers: Codefresh offers a rich set of triggers that you can select and define through the Codefresh UI as part of creating an Argo Workflow. These include Git and Cron triggers. The triggers and the event that are mapped to sensors and

Workflow Templates: Predefined library of for Argo Workflows.



Build view dashboard: The Workflows dashboard provides
See Delivery Pipelines. -->


### Applications
An application is a deployment to a Kubernetes, or any Kubernetes-compatiale cluster or clusters.
Codefresh supports two types of applications:
* Containerized applications packaged as Docker images or
* Argo CD applications

**Containerized applications**
Containerized applications are compiled, packaged, and deployed through Codefresh pipelines. Codefresh has native support for Docker artifacts, and also supports non-Dockerized applications that don’t use a Dockerfile for the actual build.

Deploy an application directly to Kubernetes through the Codefresh UI, or use Helm as a package manager to deploy to Kubernetes, again from Codefresh.
Codefresh offers several levels of visibility into your deployments :
* The Kubernetes dashboard displays the status of pods and Docker images.
* The Helm dashabord displays the applications deployed to the cluster through Helm packages.
* The Environment dashbaord displays both Helm and Kubernetes releases, the status of the cluster, and most importantly that of the builds that affect it.

See:


**Agro CD applications**
Argo CD applications conform to Argo CD's application definition CRD (Custom Resource Definition). Argo CD supports several types of Kubernetes manifests, including Jsonnet, Kustomize applications, Helm charts, and YAML/json files, and supports webhook notifications from Git.

Create Argo CD applications that are fully GitOps-compliant from the Codefresh UI. Work in form mode or directly in YAML in the Create Application wizard. Built-in validation makes it easy to identify and fix errors before commit. The application manifest is generated, committed to Git, and synced to your cluster.
After creation, you can edit and optimize the application,

Just as with Dockerized applications, you get full visibily into the applications and their deployment thorugh the global Analytics, DORA metrics, and the Application dashboards. The Applications dashboard displays the individual deployments across your enterprise. Drill down shows the current state of all the resources in the application with actions and detilaed information for each resource.



### Triggers
TBD

### Events
TBD

8 changes: 8 additions & 0 deletions _docs/getting-started/gitops-codefresh.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
---
title: "Codefresh for GitOps"
description: "Argo CD with Codefresh GitOps"
group: getting-started
toc: true
---

Work in progress TBD
Loading