10 am - group discussion to talk about servers and new configuration stuff.

- Currently all of our servers are and/or have been setup differently. That becomes a nightmare to manage.

- The server setup is done every couple of months... that makes it hard to remember what the setup process is and/or was. Our goal is to help make our environment become more stable and also more standardized.

- Wayne likes to use a program called Puppet. This allows for a master template and/or recipe to be deployed out to other serves. Similar to ghosting or cloning things. As we install and setup new serves, Wayne could then help and manage those serves. He was talking about server roles, scripts, and applying updates and changes. Setting things up and then maintaining that same type setup over time.

- If Wayne starts taking care of the servers, it enables us to spend more time developing.

- How do we deploy code to the servers? We are currently using Git (source control and version control). We are using phase one where we push code to the server. We would like to use a step 2 process where Git (our version control) actually pushes the code up to the server. When we get to the automatic level of deploying code to all servers, we need to make sure that we have all dependencies in place. This includes our database updates. Currently, the database updates are scripted and then run by users per server. Wayne is talking about a documented process that writes a chain of processes that have been run and still need to be ran.

- We just added a new server - data 11. We are going to be experimenting on that new server and using Git (source control) to push files up to that box. We are also going to be mirroring a new server configuration to help do some side-by-side testing. We are also planning on migrating corporations from data 1 (older server) to the new data 11 server. This is strategic based on trying to migrate clients off of an older server into a newer server environment.

- There is another part of this process - that is testing and running tests to make sure that things are working. Eventually, this could get into stress testing and really seeing where the code breaks and/or cracks (pressure and stress testing). Eventually (bad word), we would like the tests to help keep us upright and to verify that we are still good to go.

- Small discussion about custom code and getting to a confidence level of what is being done and managing expectations with that custom code. There is some more feedback and communication that is needed here.

- We really want this to be a group and a team effort. We are going to need help with ideas, code, migrating, testing, and deploying.

- One known dependency piece is the database update stuff. We have to make sure that the database get tweaked (the landing zone) before we push the code up. We are seeing some sort of cross process where we use Git commits and known processes (order of operations) and then match them up with a record on the actual servers. This would allow us to see code on Git/Bitbucket and also compare that with a list on the actual data servers.

- Small discussion between Windows and Linux boxes. The discussion was talking about database connection strings and where the actually database live (same server and/or remote connections) and where the server-side software exists. How do they connect. We also briefly talked about security of allowing connections between servers, clients, and databases. We are planning on testing things quite highly before anything goes live.

- At what point do you change? It comes down to the burning platform type analogy.

- Small discussion on changes to the database and the code... if brand new and no one is using it, easy pea-sy. Once it starts getting used (people are going and moving at full speed) it gets way more tuff and difficult. We are looking for a moving model and getting consistency.

- Primary goal - keep our customers happy. Secondary goal - all make some money and be able to keep going with what we are doing? Basically, we need a stable process that our customers like and have confidence in what we do and how we do it. That is awesome.

- Wayne jumped in and showed us some of the things that he is watching and monitoring. These are things like: how much memory is being used, how many connections, how many queries per timeframe, CPU usage, hard drive size, and other setting monitors. Wayne was showing us some things from his Nagios server and from his Cacti server stuff. Both are graphing and monitoring systems and what are the trends, traffic, and other server statistics.

- As a side note, we are also going to be upgrading to Adobe ColdFusion 2018 and MySQL 8. Some of the older servers are using Adobe ColdFusion 11 and MySQL 5.6 or 5.7. That should help out as well.

- We will be making changes as the need arises. We don't want to just make changes just to make changes.

- Small questions and answers between the developers and Wayne. Lots of talk about tuning, specializing, and customizing systems, hardware, software, etc. Miss configured settings and getting all of the serves tuned to the right settings. Rollover, fail over, and master/slave type topics. Database partitioning vs corp-specific tables. How do database partitions and indexing effect things? Creating independency between serves and code and serves and databases. Isolation vs shared vs other options. Live data vs old dead data (companies that are no longer using our system). Archiving data, rolling up data and totals, storage, etc. virtual machines vs actual dedicated boxes. Physical locations vs virtual locations of the servers, redundancy, backups, data centers, and even what vendors (hosts) we use. Lots of good discussions.

- Wayne and Alan were talking tons and tons about testing and testing strategies. They were also talking about getting things to the level of being able to apply stress based tests and performance tests. Basically, putting things through the paces. They were also talking about concurrent hits (multiple users doing the same thing) and managing tests based on simulated usage and what not. Good stuff.

- Picking up the low hanging fruit due to no current performance testing and/or performance configurations. As we get into this, we should be able to pick up a few of the low hanging pieces of fruit. That is exciting.

- Starting with the results in mind and then working backwards from that vs writing things and hoping for a certain result. Perception, expectations, vision, and outlook. Some great ideas. Test driven design ideas.

- At the end of meeting, Dustin was willing to help with the testing. That may be a perfect fit. Currently, he has some pretty integrated processes that he is working on and nobody is pulling on him for super tight deadlines (client requests). He is working on internal projects.