Skip to main content

As the Dev Ops Manager, I need to start planning our CI/CD release process

Part of the CI/CD Development Series

Once we have our Deployment Diagram designed, we need to figure out out to get from here to there. If the end point is the appropriate server environment, the starting point is the developer with his/her hand on the keyboard. These steps take place on a variety of machines, within various process and can changes based on what files are checked in or not.

At the moment, we've only created the early basics as seen below.
The Beginning of our Deployment Activity Chart


Even though there is quite a long way to go there are some elements which we have already been determined. For example

  • We have determined the broad strokes of our technology stack. This is going to be React on the front end and ColdFusion on the server side.
  • We have determined that we are going to be using linting on both the CF and React paths. CFLint for the CF and ESLint for the Javascript
  • We have determined that we are going to be formatters - CFFormat for CF and TBD for JS
  • We have a security testing step on the CF site which is Fixinator from Foundeo. We will look for something on the React side to complement this. 
  • We are doing automated tests for both. This will be Testbox from Ortus Solutions for the CF and, for the moment at least, Jest for the JS side. 

We've also implicitly stated that all of these steps need to take place before the code is checked into the local repo and definitely before it's checked or merged into the development branch. We'll look more on ways to automate this process in future entries. Which leads us to the other this which has also been decided which is our merging strategy. 

Merging Strategy
While there are several different options from mandating pull requests to very specified branching policies, I'd like to keep this as simple as possible and have, at least conceptually, three branches. Two of these are:

Master: This branch is always the "production ready code". In fact, each time that code is committed to this branch, it will try to be deployed so this is, by definition, the production code. 

Development: This branch is the main source for other branches in that it has the latest up to date code that has been checked in, even code that isn't ready for production yet. This code will end being deployed but to our live testing server. From the Deployment Diagrams, this is an internal facing site that our testers, management and internal review teams can view to see how things are progressing. This can be both good (they are reassured since they see things appearing and working to a point) or bad (they can wonder if they can see it, shouldn't it be live).

Developer / Feature branch: This is the branch which is basically whatever the developer is working on at the time whether it be a feature, hotfix or refactoring. As it gets complete and can be merged into the development branch, this branch can either disappear or continue depending on what is called for. 

This strategy is based on this article which I reached from the BitBucket website: https://nvie.com/posts/a-successful-git-branching-model/. Some of the items might not necessarily be apropos for a continuous deployment environment (such as versioning etc) so we can probably pare it down but we'll go into that more clearly in a different post. 









Labels:

Comments

Post a Comment

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...
6 comments
Read more

As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each one

Part of the CI/CD Development Series The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up ...
1 comment
Read more