The first step starts like the last one: cloning the Git repository. One thing to remember about Puppet environments is that a branch of this repository corresponds to a Puppet environment. Most users of Puppet don't have a master environment, but rather, the production environment that Puppet places nodes into by default. If your organization has any environments prior to production, as many do, you'll want to make sure that you begin on the existing branch before creating a new branch. The git checkout -b command creates a new branch, starting from the branch that you are currently on. The following are the steps for creating a new environment, modeled after an existing environment:
- Make a copy of the control repository from the upstream repository (git clone).
- Check out the environment that you want to write new code against (git checkout).
- Check out a new branch, based on the current branch (git checkout -b):
# This step is not needed if the repository is already on the local file system
git clone [email protected]:puppet/control-repo.git
# We'll assume integration is the pre-production branch used by the organization
# to stage changes before moving into production-like branches
# Remember, there usually is no master branch in a control repository, so we want
# to target a specific branch to work against.
git checkout integration
# If this repo has been freshly cloned, git pull shouldn't provide any new updates,
# but it's safe to run either way. If the repository has already been cloned in the
# past, you definitely want to run this command to pull the latest commits from
# upstream.
git pull origin integration
# We'll perform a second checkout, with the -b flag to indicate a new branch based on the existing branch
git checkout -b new_feature
Like the steps we took for our component module repository, this set of commands ensures that we have a local copy of the repository with the latest commits to the integration branch, and that we started a new branch based on the existing code. We're in a state to edit files found directly in our control repository, such as the Puppetfile, hieradata, and embedded roles and profiles (if you keep them in the control repository, rather than as separate, individual repositories). Once we have the code, we will want to edit the relevant files, create a new commit, push the code back to the origin repository, and deploy the environment.