Practical Octopus Deploy – Projects and Project Groups

Understanding Octopus Deploy Projects

In our last post, we explored lifecycles in Octopus Deploy. In this post, we’ll examine Octopus Deploy projects and project groups. We’ll see how projects help to define your deployments. We’ll look at how project groups help organize your projects, and also how they play a role in providing security. And we’ll also see how an Octopus project uses a lifecycle to control a project’s deployment model. This is the fourth post in a multi-part series about using Octopus Deploy.

Project as jigsaw puzzle
Figure 1: Project as puzzle

A Book of Recipes

Ultimately, the point of using a tool like Octopus is to deploy some software. The project is where you define a set of deployment steps. It is also one of the places in Octopus where you can configure the variables that your deployment needs. I plan to talk about deployment steps and variables in much more depth in a future post.

According to the Octopus Deploy documentation on Projects:

A project is like a recipe – you define how your software is deployed, and then you create many releases to deploy different versions of that software.

Step by Step

Among other things, it is inside the Octopus project where you select and configure deployment steps, and where you configure at least some of the variables. The process steps define what happens during a deployment. Then, among other things, the variables help define how a deployment happens.

The project is also where you choose a lifecycle for your project, which we discussed in the previous post. In turn, each lifecycle phase controls to which environment your project can be deployed, or more generally where a deployment happens.

Understanding Octopus Deploy Project Groups

Octopus Deploy project groups help organize projects. Each project group contains a set of projects. You may think about it as being similar to a folder.

In the Octopus security model, access to individual projects can be limited to specific user teams. In this case, the administrator must grant a team access to each new project, one-by-one. However, with a recent release of Octopus, access may be granted at the project group level. In that case, when adding a new project to a project group, it automatically becomes visible to all users that can see that group.

I Can See Paradise by the Dashboard Lights

For example, Figure 2 shows an Octopus dashboard. The logged in user has rights only to the DCJ project group, so that is all that is available on this user’s dashboard. In turn, the DCJ project group contains three projects: Approval_Test, CMP, and JJIS_SSIS.

Several Octopus Deploy projects shown on the dashboard
Figure 2: An Octopus dashboard

Across the top of the project group, you can see the names of all the environments available for deployment from this project group. Within the grid, note the status, release number, and deployment date of each of the various projects. Green boxes with white checkmarks are good! Also, you’ll notice that the CMP project, which is a work in process, has never yet been advanced beyond the DEV environment. On the other hand, in the Approval_Test project, Version 0.0.12 has gone all the way to PRD, while Version 0.0.13 has advanced through DEV and QAT.

Finally, observe that there is an icon next to the name of each project in the grid. Within the Settings section of a project, you can import a custom logo. There are, of course, additional settings to help configure each project.

Continuing On

The intent of this blog post was to provide enough background information about Octopus projects and project groups to a developer who is new to Octopus Deploy. As we’ve seen, you can use project groups to organize your projects. You can nest projects inside these groups. And Octopus Deploy projects define the deployment steps and variables that you use to create a deployment process. A future post will discuss deployment steps and variables in detail.

This is the fourth post in the multi-part series – “Practical Octopus Deploy.” The focus of this series is from the perspective of a developer who wishes to use Octopus to deploy an application. The next post in this series discusses using database change scripts with Octopus Deploy. The first post, with table of contents, is Practical Octopus Deploy – Introduction.

Additional Resources

Here are some additional resources for you to study on these two topics. There might be a quiz later.

Author: Russ Warner

I'm a senior software developer living near Portland, Oregon.

Leave a Reply